[13:14] <italy> :)
[18:00] <jdstrand> hi!
[18:00] <tyhicks> Hello
[18:00] <mdeslaur> \o
[18:00] <jdstrand> #startmeeting
[18:00] <meetingology> Meeting started Mon Jan 28 18:00:31 2013 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:00] <jdstrand> nice to start on time today :)
[18:00] <jdstrand> The meeting agenda can be found at:
[18:00] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[18:00] <jdstrand> [TOPIC] Announcements
[18:01] <jdstrand> Christian Kuersteiner (ckuerste) provided debdiffs for lucid-oneiric for xymon (LP: #1092412)
[18:01] <jdstrand> Christian Kuersteiner (ckuerste) provided debdiffs for quantal for ruby-actionpack-3.2 (LP: #1100188)
[18:01] <jdstrand> Christian Kuersteiner (ckuerste) provided debdiffs for quantal for ruby-activerecord-3.2 (LP: #1100188)
[18:02] <jdstrand> thanks to ckuerste for his help on security updates for these community supported packages. Your work is very much appreciated and will keep Ubuntu users secure. Great job! :)
[18:02] <jdstrand> [TOPIC] Weekly stand-up report
[18:02] <jdstrand> I'll go first
[18:03] <jdstrand> last week I was community and I patch piloted
[18:03] <jdstrand> this week I've got a chromium-browser upload to sponsor/test
[18:03] <jdstrand> and two embargoed issues
[18:04] <jdstrand> I'd like to take another look at our blueprints as well
[18:04] <jdstrand> I plan to finish a couple of outstanding audits as well
[18:04] <jdstrand> mdeslaur: you're up
[18:04] <mdeslaur> I just published a couple of USNs
[18:04] <mdeslaur> and I have something embargoed to look at
[18:04] <mdeslaur> and then will continue going down the CVE list
[18:04] <mdeslaur> I'm on triage this week too
[18:05] <mdeslaur> that's it, sbeattie you're up
[18:05] <sbeattie> I'm still focused on apparmor this week, specifically the display manager mediation prototype.
[18:06] <sbeattie> that's prettymuch it for me. tyhicks?
[18:06] <tyhicks> I'm working on an embargoed item
[18:07] <tyhicks> I also need to upload new dbus and linux packages to the dbus-dev PPA for some patches that'll allow dbus to detect if apparmor supports dbus rules
[18:07] <tyhicks> Then I'll (re)start work on the AppArmor kernel policy interface workitem
[18:07] <tyhicks> That's it for me
[18:07] <tyhicks> jjohansen: you'r eup
[18:09]  * jjohansen is working on the apparmor label and stacking code again, and we should see a new patchset this week. Currently I am chasing down a refcounting bug that is causing oopses
[18:10] <jjohansen> after the new patchset gets pushed, /me will be moving on to env var filtering
[18:10] <mdeslaur> \o/
[18:10] <jdstrand> \o/
[18:11] <jjohansen> sarnold: I think your up next
[18:11] <sarnold> the dnsmasq patchset just kept growing, I handed off a braindump and four debdiffs to mdeslaur last week, it's a bit annoying to feel defeated by an update, but it's nice to look forward to something more approachable this week :)
[18:12] <mdeslaur> sarnold: hehe, don't worry about that :)
[18:12] <sarnold> this week I'm working on an update for squid and reviewing jjohansen's patches
[18:12] <sarnold> I'm also on community :)
[18:12] <sarnold> jdstrand: your turn :)
[18:12] <mdeslaur> sarnold: cool. Squid is your priority this week.
[18:13] <sarnold> mdeslaur: thanks
[18:13] <mdeslaur> sarnold: I'd like to see squid published on thursday
[18:13] <mdeslaur> sarnold: and if you still need testing, it can get pushed back to monday
[18:14] <mdeslaur> sarnold: is that reasonable?
[18:14] <sarnold> mdeslaur: I think so
[18:14] <mdeslaur> sarnold: cool, thanks
[18:15] <jdstrand> [TOPIC] Highlighted packages
[18:15] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[18:15] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/mathopd.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/elinks.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/openarena.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libsmi.html
[18:16] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/geshi.html
[18:16] <jdstrand> Also, there are a lot of merge opportunities for packages listed in http://people.canonical.com/~ubuntu-security/d2u/. Performing these updates is a great way to help Ubuntu and bolster your developer application.
[18:17] <jdstrand> [TOPIC] Miscellaneous and Questions
[18:17] <jdstrand> Does anyone have any other questions or items to discuss?
[18:23] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold: thanks!
[18:23] <jdstrand> #endmeeting
[18:23] <meetingology> Meeting ended Mon Jan 28 18:23:39 2013 UTC.
[18:23] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-28-18.00.moin.txt
[18:23] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-28-18.00.html
[18:23] <jjohansen> thanks jdstrand
[18:23] <sarnold> thanks jjohansen
[18:23] <tyhicks> thanks!
[18:23] <mdeslaur> thanks jdstrand!
[18:23] <sarnold> hehe
[18:23] <sarnold> thanks jdstrand :)
[18:23] <jjohansen> haha
[18:24] <jdstrand> :)
[18:24] <sbeattie> thanks jdstrand
[19:05] <tumbleweed> !dmb-ping
[19:06]  * barry waves
[19:06]  * stgraber waves
[19:07]  * micahg is here, but might lag
[19:07] <tumbleweed> I think that makes us mostly quorate
[19:07] <tumbleweed> #startmeeting Developer Membership Board Meeting
[19:07] <meetingology> Meeting started Mon Jan 28 19:07:30 2013 UTC.  The chair is tumbleweed. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[19:07] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[19:07] <tumbleweed> #topic Review Previous Action Items
[19:08] <tumbleweed> * DMB members to read proposal for lightweight amending of ppu rights (for dds) and be prepared to vote next meeting on next action.
[19:08]  * bdrung arrives.
[19:08] <tumbleweed> bdrung: don't you want to take over? :)
[19:08] <tumbleweed> #chair bdrung
[19:08] <meetingology> Current chairs: bdrung tumbleweed
[19:09] <bdrung> tumbleweed: nope :p
[19:09] <tumbleweed> aww
[19:09]  * bdrung needs to mentally arrive.
[19:09] <stgraber> oops, forgot to read the proposal before the meeting, just did that now though ;)
[19:09]  * tumbleweed digs through e-mail to find it
[19:10] <stgraber> http://people.ubuntu.com/~laney/dynamic-ppu-procedure.txt
[19:12] <tumbleweed> do we want to vote on adopting this?
[19:12] <stgraber> I think so, yes.
[19:12] <bdrung> yes
[19:12] <tumbleweed> #vote Adoption of Dynampic PPU Procedure
[19:12] <meetingology> Please vote on: Adoption of Dynampic PPU Procedure
[19:12] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[19:12] <bdrung> +1
[19:12] <meetingology> +1 received from bdrung
[19:12] <tumbleweed> +1
[19:12] <meetingology> +1 received from tumbleweed
[19:13] <barry> +1
[19:13] <meetingology> +1 received from barry
[19:13] <micahg> +1
[19:13] <meetingology> +1 received from micahg
[19:13] <stgraber> +1
[19:13] <meetingology> +1 received from stgraber
[19:13] <tumbleweed> #endvote
[19:13] <meetingology> Voting ended on: Adoption of Dynampic PPU Procedure
[19:13] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[19:13] <meetingology> Motion carried
[19:13] <tumbleweed> Great, adopted
[19:14] <tumbleweed> #action laney to publish that somewhere
[19:14] <meetingology> ACTION: laney to publish that somewhere
[19:14] <tumbleweed> #subtopic DMB to sort out re-election stuff.
[19:14] <tumbleweed> who is driving this election? micahg?
[19:14] <micahg> I guess I am
[19:15] <tumbleweed> ok. Anything we need to discuss?
[19:15] <barry> well, voting is supposed to start today
[19:15] <micahg> nothing in public that I"m aware of, save that it will probably be a 10-12 day voting period, is that ok?
[19:15] <barry> lasting until 11-feb
[19:15] <bdrung> don't we discuss the nominees?
[19:16] <micahg> in public?
[19:16] <barry> (according to the laney's announcement)
[19:16] <bdrung> just confirm who is on the list
[19:17] <tumbleweed> I don't see a major problem with a 10-12 day voting period
[19:17] <micahg> bdrung: I don't think so, but we'll discuss amongst ourselves
[19:17] <tumbleweed> but would prefer it if we could start it tomorrow, and end it on midnight 10-11th (or something like that)
[19:17] <micahg> yeah, that's what I would like to do as well
[19:18] <tumbleweed> ok, cracking on
[19:18] <tumbleweed> #topic Review any packageset descriptions that have been received (micahg)
[19:18] <tumbleweed> lol
[19:18] <tumbleweed> (I assume there are none)
[19:19] <micahg> no, I do have to finish that...
[19:19] <tumbleweed> #topic Aron Xu's application for upload rights to im-config and other pkg-ime packages
[19:20] <tumbleweed> but he doesn't appear to be here
[19:20] <tumbleweed> poked on IRC
[19:20]  * barry could have sworn we had two applications today
[19:21] <micahg> umm, it would be an odd time for him
[19:21] <tumbleweed> barry: did you get any reply to your mail to him about the meeting slot?
[19:22] <bdrung> barry: Paul Gevers moved his application to the March 25, 2013 meeting
[19:22] <happyaron> Hi
[19:22] <tumbleweed> happyaron: hi
[19:22] <barry> happyaron: hi!
[19:22] <tumbleweed> sorry, should have pinged you earlier
[19:23] <tumbleweed> would you care to introduce your application?
[19:23] <happyaron> it's my mistake to not getting the time right...
[19:23] <tumbleweed> this probably should have been a 14:00 UTC meeting, wasn't the last one 19:00?
[19:23] <happyaron> okay, let me introduce.
[19:23] <micahg> tumbleweed: I commented as such, but was told I was wrong :)
[19:24]  * barry was confused by that this morning too
[19:24]  * stgraber too
[19:24] <tumbleweed> ok, back to happyaron
[19:25] <happyaron> well, it was because input method support isn't very well in Ubuntu, and I'm currently one of the most active person on it in Debian. Advised by Daniel a year before, I decided to apply for PPU recently, to work more directly in Ubuntu to make sure more people get benefited from my work.
[19:26] <happyaron> Input method is something very important for its users (like me), and it's not that easy to get the point for people who don't use it.
[19:27] <tumbleweed> thanks happyaron
[19:28] <tumbleweed> micahg: you have a qustion?
[19:28] <micahg> happyaron: are you asking for PPU for all IME packages or just a subset?
[19:28] <micahg> err..all pkg-ime packages
[19:28] <happyaron> yup
[19:29] <happyaron> plus im-config
[19:29]  * tumbleweed wonders why im-config isn't in pkg-ime
[19:29] <bdrung> happyaron: which input method do you use and which language do you write?
[19:29] <happyaron> tumbleweed: because there are people don't like pkg-ime, like most Japanese maintainers.
[19:30] <happyaron> bdrung: I used SCIM for three years before IBUS, and IBus for two years before switching to Fcitx, and Fcitx for two years till now.
[19:30] <happyaron> bdrung: I'm a native speaker of Chinese Mandarin.
[19:32] <micahg> happyaron: in your various sponsored uploads to Ubuntu, have you had any interaction with the release team and/or the release process, including freezes?
[19:35] <happyaron> micahg: yes but not very much in deep freeze. Ubuntu used to upload cutting-edge IBus to its archive with unstable features pushed out by RH, and it's embarrassing in a freeze. Actually some versions of IBus are quite stable, and most of my work is to persuade people sync or not sync a version of the software at some points of the release.
[19:36] <micahg> happyaron: right, I'm interested in that sync or not sync part :)
[19:36] <happyaron> For fcitx, I coordinate the release with upstream to make sure the version we want to have in Ubuntu just-in-time for FFe.
[19:38] <happyaron> micahg: Looking at the version of IBus in previous Ubuntu releases, some of them are shipt with ibus 1.x.99999 version, which is a beta version of ibus 1.(x+1).
[19:39] <happyaron> At that time I was usually pushed by local users to communicate with upstream about the issue, and then try to apply as many as patches that upstream/me consider suitable.
[19:40] <micahg> happyaron: so, if you had the choice, would you prefer the beta or the old stable?
[19:40] <happyaron> micahg: old stable
[19:41] <tumbleweed> happyaron: I'm interested in why you are applying for uplaod rights to im-config, which you've never uploaded in either Debian or Ubuntu?
[19:41] <happyaron> even beta has many more long waited features, it doesn't worth to make it unstable. If it doesn't work for a user, it's just like you don't have a keyboard when using a PC.
[19:42] <happyaron> tumbleweed: Actually I've started working on im-switch/im-config for more than a year, but Osamu would like to have every patch pass his eyes, so I leave all the final decisions to him.
[19:42] <tumbleweed> ah
[19:42] <tumbleweed> so, what are you intending to do with the upload rights? sync after Debian Import Freeze?
[19:44]  * tumbleweed is interested to see that ibus has never had an SRU - so either we are shipping fairly stable releases, or nobody is fixing the problems in it :)
[19:44] <happyaron> tumbleweed: partially, added intention is about making sure that I can get SRU easily.
[19:45] <happyaron> because the beta version ibus doesn't worth the work for SRU
[19:45] <happyaron> If you want to fix critical bugs, SRU to a stable version is the best choice. Another reason is the indicator patches.
[19:47] <tumbleweed> it sounds like the best way to represent the pkg-ime packages is as a packageset
[19:47] <happyaron> During every release cycle, there must be someone porting the indicator patches to new version of ibus and/or indicator, there is no such interest in the community to work on those stuff - which are very probably needs re-do in next release
[19:48] <tumbleweed> happyaron: right
[19:48] <happyaron> I was advised to apply for a team, but I think I need to get used to everything first before doing in that way, :-)
[19:49] <stgraber> happyaron: so, let's say that a new upstream release of im-config is released on the 12nd of March and that it contains critical fixes you want to see in Ubuntu. What would you do (please note the date, it's important)?
[19:50] <happyaron> stgraber: it still depends on how big is the changes and how it's important.
[19:50] <stgraber> happyaron: "critical fixes you want to see in Ubuntu"
[19:52] <happyaron> stgraber: it's ambiguous for me actually, I'm a DD with experience of nearly two Debian releases already (say Wheezy for 2nd).  It's better to have known problems than introducing new ones.
[19:55] <stgraber> happyaron: ok. In this particular case, the 12nd of March is after FeatureFreeze, so you can't upload anything that contains more than bugfixes without a freeze exception. Additionnaly, the 13th is the beta1 release for some flavours, so you'd want to contact those too to check if they're interested in the fix.
[19:55] <stgraber> happyaron: do you know where you can find information about those dates? (FeatureFreeze, beta1, ...)
[19:55] <happyaron> ReleaseSchedule
[19:55] <stgraber> good
[19:55] <stgraber> happyaron: are you subscribed to ubuntu-devel-announce?
[19:56] <happyaron> Already for years.
[19:57] <stgraber> also note (with my release team member hat on) that we don't need any freeze exception or really anyone contacting us for bugfix uploads. That documentation and dialog is only required if the upload will cause feature change.
[19:57] <bdrung> happyaron: the freeze in Debian is different than the freeze in Ubuntu. We have a _feature_ freeze in Ubuntu. So bug fixes are allowed.
[19:57] <micahg> happyaron: also, please keep in mind that the release criteria in Ubuntu and Debian are different, in that if you have a good case, you might be able to get a new upstream version in
[19:58] <stgraber> Though for bugfix uploads, you should still make sure the archive isn't in some kind of freeze (full or partial) due to a milestone coming up. In those case, it's recommended to poke #ubuntu-release even for bugfixes (for any seeded package)
[19:58] <stgraber> happyaron: do you know how to check if a package is seeded (on a media that we ship)?
[19:58] <happyaron> bdrung: I know that, but what I did perviously were usually submitting FFe for those crashing stuff, unfortunately.
[19:58] <happyaron> stgraber: there is a bzr branch
[19:59] <happyaron> micahg: I see, that's what FFe for.
[19:59] <micahg> yeah
[19:59] <stgraber> happyaron: yeah, but the bzr branch makes it really difficult to know what's actually seeded because it doesn't contain the dependencies/build-dependencies of those packages
[19:59] <stgraber> happyaron: instead we have a "seeded-in-ubuntu" tool you can use for that
[19:59] <happyaron> nice to know, what's that?
[20:00] <happyaron> got it.
[20:00] <tumbleweed> ok, I think we should wrap this up and take it to a vote
[20:01] <tumbleweed> I'm suggesting we create an input-methods packagset, which we can describe as
[20:01] <tumbleweed> packages maintained by the pkg-ime team in Debian, and im-config
[20:01] <tumbleweed> it's a bit of an odd description, but it covers the packages you are asking for. objections?
[20:02] <stgraber> (note that the DMB won't keep it in sync, instead we expect to be contacted when something is added to pkg-ime)
[20:02] <happyaron> stgraber: I see, I'll contact DMB when needed.
[20:02] <tumbleweed> that can be done by e-mail
[20:02] <tumbleweed> ok
[20:03] <tumbleweed> #vote Grant Aron Xu upload rights to a input-methods packagset (pkg-ime packages and im-config)
[20:03] <meetingology> Please vote on: Grant Aron Xu upload rights to a input-methods packagset (pkg-ime packages and im-config)
[20:03] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[20:04] <stgraber> +1 [glad to see someone stepping up to maintain those often forgotten yet important packages]
[20:04] <meetingology> +1 [glad to see someone stepping up to maintain those often forgotten yet important packages] received from stgraber
[20:04] <barry> +1
[20:04] <meetingology> +1 received from barry
[20:04] <tumbleweed> +1 [ actively involved in these packages upstream and Debian. I'm confident they'll be well looked after in Ubuntu ]
[20:04] <meetingology> +1 [ actively involved in these packages upstream and Debian. I'm confident they'll be well looked after in Ubuntu ] received from tumbleweed
[20:04] <bdrung> +1 (good to have someone maintaining the package who uses it)
[20:04] <meetingology> +1 (good to have someone maintaining the package who uses it) received from bdrung
[20:04] <micahg> +1 good packaging history in Debian and Ubuntu
[20:04] <meetingology> +1 good packaging history in Debian and Ubuntu received from micahg
[20:05] <tumbleweed> #endvote
[20:05] <meetingology> Voting ended on: Grant Aron Xu upload rights to a input-methods packagset (pkg-ime packages and im-config)
[20:05] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[20:05] <meetingology> Motion carried
[20:05] <stgraber> tumbleweed: I
[20:05] <stgraber> 'll create the package set
[20:05] <tumbleweed> stgraber: thanks
[20:05] <happyaron> thanks all, :)
[20:05] <tumbleweed> happyaron: congratulations :)
[20:06] <stgraber> and I'll also take care of the team, that way it'll be setup the way I like it ;)
[20:06] <micahg> happyaron: congratulations
[20:06] <tumbleweed> hah
[20:06] <bdrung> happyaron: congrats and welcome.
[20:06] <happyaron> :)
[20:06] <stgraber> happyaron: congrats
[20:06] <tumbleweed> #topic Any other business?
[20:07] <tumbleweed> next chair?
[20:07] <stgraber> happyaron: I'm a tiny bit busy at the moment but I should have all of the admin stuff sorted by this time tomorrow. If you need to upload something before that, ping me and I'll sponsor.
[20:08] <tumbleweed> bdrung, with Laney as backup, I think
[20:08] <bdrung> so soon again?
[20:08] <tumbleweed> I last chaired two meetings ago...
[20:08] <happyaron> stgraber: thank you, I think I won't need that in several days, I'll need work on new versions of IBus and Fcitx this week(end) before uploading.
[20:09] <happyaron> excuse me that I must leave now, it's already 04:08AM in Beijing and I'm missing my bed...
[20:09] <tumbleweed> yup, I think we're done here
[20:09] <tumbleweed> #endmeeting
[20:09] <meetingology> Meeting ended Mon Jan 28 20:09:32 2013 UTC.
[20:09] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-28-19.07.moin.txt
[20:09] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-01-28-19.07.html
[20:09] <tumbleweed> thanks everyone
[20:09] <barry> thanks tumbleweed !
[20:09] <stgraber> thanks!
[20:09] <stgraber> happyaron: good night :)
[20:10] <happyaron> thanks, and good day/night, :)


[08:09] <Chipaca> good morning all!
[08:13] <jam> Chipaca, morning chipaca, how goes ?
[08:13] <jam> btw, I was quite impressed how much text you churned out
[08:16] <Chipaca> jam: goes well! brain isn't booted yet but getting there
[08:16] <jam> Chipaca, I have my coffee machine back, want the first cup ?
[08:17] <Chipaca> jam: i got my coffee delivered! there's still last week's delivery missing but i'm back in stock at least
[08:17] <Chipaca> jam: woke up in the night when it clicked that we could use charmcraft.yaml to have an 'install' section for the non-python reqs
[08:17] <Chipaca> *hand waving intensifies*
[08:18] <jam> no unicode jazz hands
[08:18] <Chipaca> 👐 no?
[08:19] <jam> "open hands" isn't quite jazz hands to me but good enough 👐
[08:19] <jam> jazz hands aren't next to each other
[08:19] <Chipaca> "🤗" is supposed to be "hugging face"
[08:19] <Chipaca> but "hugging face" is that face-hugger alien parasite thing
[08:19] <Chipaca> so no thanks
[08:26] <jam> "hugging face" isn't that choking someone?
[08:26] <jam> I know I don't usually hug with narrow hands
[08:59]  * jam lunches
[09:20]  * Chipaca is having way too much fun
[10:48] <facubatista> Muy buenos días a todos!
[10:58] <Chipaca> facubatista: 👋 :-)
[11:44] <Chipaca> we're lying liars: we're not logging events when dispatch is in use :-( i'll file a bug
[11:50] <facubatista> Chipaca, Natalia is gmt+3, Moscow
[11:50] <Chipaca> natalia is also gmt-3, uruguay
[11:50] <facubatista> :)
[11:50] <Chipaca> a conspiracy of natalias
[11:50] <facubatista> mirrors!
[11:51] <facubatista> speaking of that, I'm no longer the one and only Facundo
[11:51] <facubatista> #eselacabose
[11:53] <Chipaca> facubatista: whaaaa
[11:54] <Chipaca> facubatista: sacrilege!
[11:54] <facubatista> indeed
[11:55] <Chipaca> facubatista: and their irc nick is cooler than yours
[11:55] <Chipaca> facubatista: oh the shame
[11:55] <facubatista> :)
[11:56]  * Chipaca goes to make lunch
[16:33] <Chipaca> grah
[16:33] <Chipaca> need to take a break before testing the last bit :) and then some failing integration ones and then i'm done
[16:56]  * Chipaca steps away for a while
[17:47] <facubatista> Chipaca, something I hate about pathlib.Path is that if you print its str(), it may be misleading (spaces in the middle, etc), but if you print its repr(), the whole "pathlib.Path" is shown... I end up doing "path: {!r}".format(str(path))
[18:25]  * facubatista bb~1h
[18:54] <Chipaca> facubatista: I didn't understand why spaces in the middle would be misleading, but that's ok, you can be wrong :-p
[19:34]  * facubatista is back
[19:35] <facubatista> Chipaca,
[19:35] <facubatista> >>> p1 = pathlib.Path("foo bar")
[19:35] <facubatista> >>> p2 = pathlib.Path("baz")
[19:35] <facubatista> >>> print(p1, p2)
[19:35] <facubatista> foo bar baz
[19:36] <facubatista> ugly: >>> print("{!r} {!r}".format(p1, p2))
[19:36] <facubatista> PosixPath('foo bar') PosixPath('baz')
[19:36] <facubatista> what I end up doing: >>> print("{!r} {!r}".format(str(p1), str(p2)))
[19:36] <facubatista> 'foo bar' 'baz'
[19:48] <Chipaca> facubatista: y tho
[19:48] <Chipaca> in what context is 'print(p1, p2)' something you'd actually want to do?
[19:49] <facubatista> Chipaca, it was an example
[19:49] <Chipaca> ok
[19:49] <facubatista>             raise CommandError("the charm entry point was not found: {!r}".format(str(arg)))
[19:50] <facubatista> Chipaca, ^
[19:50] <facubatista> Chipaca, think for example if you called it like --entrypoint="mycharm.py "
[19:51] <facubatista> of course the last space is a type
[19:51] <facubatista> *typo
[19:52] <facubatista> >>> print("the charm entry point was not found: {}".format(arg))
[19:52] <facubatista> the charm entry point was not found: mycharm.py
[19:52] <facubatista> >>> print("the charm entry point was not found: {!r}".format(str(arg)))
[19:52] <facubatista> the charm entry point was not found: 'mycharm.py '
[19:52] <Chipaca> facubatista: hmm. repr in this context is something that is almost but not always what you want for strings even
[19:52] <facubatista> of course, I won't be using print, but logging it, but it's the same
[19:53] <facubatista> Chipaca, why I don't like it?
[19:53] <facubatista> s/like/want/
[19:55] <Chipaca> facubatista: consider what happens if you specify a filename that's not ascii, and you need it to be ascii
[19:55] <Chipaca> facubatista: repr won't help highlight the problem
[19:55] <facubatista> Chipaca, what do you mean "need it to be ascii"?
[19:56] <Chipaca> e.g. "the filename must be a-z0-9: {!r}".format("реасе")
[19:57] <Chipaca> facubatista: that won't say what the problem is in any way, for most users
[19:57] <Chipaca> some might though
[19:59] <facubatista> Chipaca, getting the pathlib.Path() in the middle won't improve that either
[19:59] <facubatista> Chipaca, you say to just use str() because there are corner cases that repr() won't be enought?
[19:59] <facubatista> *enough
[19:59]  * facubatista is too tired to write properly
[20:00] <Chipaca> facubatista: no, I'm saying that relying on repr() is sloppy :)
[20:00] <Chipaca> facubatista: the fact that it mostly, but not always, works for strings has made you think it's ok to do but it isn't really
[20:00] <Chipaca> facubatista: i'm not sure i'm making sense either
[20:01] <Chipaca> it's been a long week and there's a whole 'nother day of it to go still
[20:03] <facubatista> Chipaca, I'd love to find a repr_posta_posta() :)
[20:04] <facubatista> I don't want to start marking differently every non-ascii char, it would mess up the error message for people using mostly non-ascii stuff
[20:11] <MarkMaglana> whoa i caught you guys still awake!
[20:12] <MarkMaglana> ...right?
[20:12] <MarkMaglana> no?
[20:25] <Chipaca> MarkMaglana: "awake"
[20:25] <MarkMaglana> kina awake then?
[20:28] <Chipaca> MarkMaglana: fractionally awake
[20:28] <Chipaca> MarkMaglana: not actually working
[20:28] <Chipaca> at least, me
[20:28] <Chipaca> facu might be at it still
[20:28] <MarkMaglana> i just woke up at 4AM my time to check on my tomb raider download. so i won't be working either for an hour or two.
[20:38] <facubatista> MarkMaglana, which tomb raider?
[20:38] <MarkMaglana> don't laugh
[20:39] <MarkMaglana> the first one of the reboot.
[20:40] <facubatista> MarkMaglana, you're talking about the videogame or the movie?
[20:40] <MarkMaglana> the videogame lol
[20:40] <facubatista> ah, jajaja
[20:41]  * facubatista never played tomb raider
[20:42] <facubatista> actually, I remember installed and tried one, like 300 or 400 years ago, and my HW was too slow for it, and I dropped it, never tried again
[20:43] <MarkMaglana> facubatista i've been wanting to play this since it came out but with family duties it was impossible. also, i was too cheap to buy a powerful enough machine to handle the graphics until this year. so with all this lockdown and all i figured it'd be a good time lol.
[20:43] <facubatista> :D
[20:43] <facubatista> MarkMaglana, enjoy it!
[20:43] <MarkMaglana> facubatista: thanks!
[20:46] <Chipaca> facubatista: you should be able to play the original one on qemu on a raspberry pi
[20:46] <Chipaca> :)
[20:47] <Chipaca> anyway, i'm out
[20:47] <Chipaca> 👋
[20:49] <MarkMaglana> \o alrighty folks, i'll take it from here lol
[21:09]  * facubatista eods


[00:12] <skaet_> Riddell, are you going to create a https://help.ubuntu.com/community/NattyUpgrades/Kubuntu page for alpha1?
[00:15] <skaet_> Riddell, ScottK - can you confirm that http://releases.ubuntu.com/kubuntu/natty/alpha-1/ (Kubuntu)  is where the Kubuntu images will be going tomorrow.
[00:16]  * cjwatson remembers to disable daily CD builds, in the nick of time
[00:16] <cjwatson> skaet_: early milestones don't go to releases
[00:16] <cjwatson> skaet_: http://cdimage.ubuntu.com/kubuntu/releases/natty/alpha-1/
[00:16] <skaet_> cjwatson thanks.
[00:16] <skaet_> :)
[00:16] <skaet_> will edit.
[00:19] <skaet_> cjwatson, my connection started acting up, and I lost part of the last hour of IRC traffic, do we have the packaged fix from desktop team?  (ie,  have the builds started?)
[00:19] <cjwatson> the publisher's done
[00:20] <cjwatson> skaet_: it'd be good if you could do the CD builds though - getting kind of late heere
[00:20] <cjwatson> *here
[00:20] <cjwatson> I think the sequence we want is:
[00:20] <cjwatson> buildlive ubuntu daily-live && for-project ubuntu cron.daily-live
[00:20] <cjwatson> for-project ubuntu cron.daily
[00:20] <cjwatson> buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd
[00:20] <cjwatson> buildlive edubuntu-dvd dvd && for-project edubuntu cron.dvd
[00:21] <cjwatson> and possibly, if so probably before the DVDs:
[00:21] <cjwatson> buildlive ubuntu-netbook daily-preinstalled && for-project ubuntu-netbook cron.daily-preinstalled
[00:22] <skaet_> understand its late, and appreciate you're staying up so far.
[00:23] <skaet_> let me get started with the first step, and then if environment's good,  I'll work through them.
[00:23] <cjwatson> BTW, the desktop fix: https://launchpad.net/ubuntu/+source/unity/3.2.2-0ubuntu2
[00:24] <skaet_> thanks!
[00:24] <skaet_> was going to ask about that... ;)
[00:24] <cjwatson> I'm doing a source DVD build as well, but that shouldn't interfere, can work in parallel
[00:25] <cjwatson> I think you should assume that ubuntu-netbook preinstalled needs to be rebuilt unless you hear otherwise from #ubuntu-testing, since it does contain unity
[00:25] <skaet_> ok
[00:28] <rickspencer3> hmm
[00:31] <skaet_> cjwatson screen session resumed from oct, ok. ubuntu daily-live started...  can you check looks ok from your point?
[00:33] <cjwatson> it's running the right commands thus far
[00:33] <cjwatson> not sure that says very much, but anyway :)
[00:34] <skaet_> heh
[00:35] <skaet_> will bug some of the other release team members if it looks like its going in the weeds...  sleep well.
[02:09] <skaet_> ubuntu desktop i386 and amd64 are available on the iso tracker now (20101202)
[02:57] <skaet_> ubuntu alternates for i386 and amd64 are availabe on iso tracker now (20101202)
[04:30] <skaet_> ubuntu netbook preinstalled omap4 is available on the iso tracker (20101202)
[05:50] <pitti> Good morning
[06:06] <skaet_> good morning pitti
[06:06] <skaet_> ubuntu dvd for i386 and amd64 have just been posted to iso tracker.
[06:07] <skaet_> edubuntu is now building.
[06:07] <skaet_> not sure if highvoltage will want to move up to it or not though.
[06:08] <skaet_> haven't seen any bugs flagged against his 20101130 runs, but ... could be impacted by the bug fixed this afternoon.  not sure.
[06:10] <skaet_> pitti,  could you keep an eye on the builds on animony, and when the edubuntu finishes, see if highvoltage want's it uploaded to iso tracker or not?
[06:10] <skaet_> antimony even...
[06:11]  * skaet_ is feeling like its time to zzzz...
[06:13] <pitti> skaet_: sure, will do
[06:13] <pitti> skaet_: I guess we can post it either way, and then choose to release it or not
[06:13] <skaet_> thanks pitti!
[06:13] <pitti> highvoltage: ^ does that work for you?
[06:58] <pitti> highvoltage, skaet_: ah, since the current edubuntu DVDs are fully tested already, perhaps I sholdn't post them without highvoltage's exlicit ack
[08:11] <pitti> skaet_, highvoltage: http://cdimage.ubuntu.com/edubuntu/dvd/20101202/ is ready; do you want this as a1 candidate, or the already tested 1130 one?
[09:56] <apw> skaet_, when doing iso testing which desktop option are we meant to be testing
[09:56] <apw> (as there are now two, and depending on h/w you get a different one)
[10:12] <ogra> skaet_, so armel is blocked by bug 683683
[10:12] <ubot4`> Launchpad bug 683683 in klibc (Ubuntu Natty) (and 3 other projects) "run-init on omap3, omap4 in natty dies with "run-init: Unknown error 17718852" (affects: 3) (dups: 1) (heat: 26)" [High,Invalid] https://launchpad.net/bugs/683683
[10:12] <ogra> (its not klibc but busybox)
[11:31] <cjwatson> ogra: why busybox?  run-init's in klibc
[11:32] <cjwatson> oh, right, reading the bug now ...
[11:32] <cjwatson> ogra: any way I can try this under emulation?
[11:49] <Riddell> bug 684059 seems a bit of a showstopper for kubuntu, am investigating
[11:49] <ubot4`> Launchpad bug 684059 in ubiquity (Ubuntu) "Kubuntu Live Session/Installer: NameError: global name 'QWidget' is not defined in /usr/lib/ubiquity/frontend/kde_components/PartAuto.py (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/684059
[12:18] <cjwatson> Riddell: should be http://paste.ubuntu.com/538959/, right?
[12:31] <Riddell> cjwatson: yes that's right
[12:31] <Riddell> not sure how it managed to work before
[12:31] <Riddell> CD installs fine apart from that issue
[12:31] <Riddell> cjwatson: can we do an ubiquity upload then?
[12:49] <cjwatson> please go ahead
[13:09] <ogra> cjwatson, no idea why busybox, but replacing busybox-initramfs makes it work, i doubt you can try that in emulation easily since its in initramfs
[13:10]  * ogra just did a build without -marm (though that shouldnt do anything) and under the maverick toolchain
[13:10] <ogra> lets see if i can get it booting
[13:24] <ogra> cjwatson, fyi the above boots
[13:24]  * ogra has to find out if its -marm or the natty toolchain getting in our way here
[13:24] <ogra> will do another rebuild now
[13:25] <cjwatson> we only use -marm because you said something else broke beforehand :)
[13:26] <ogra_ac> yes, that was thumb2 back in lucid and maverick
[13:26] <ogra_ac> i guess we can drop it today
[13:26] <ogra_ac> but i really doubt it is the issue
[13:26] <ogra_ac> i bet on the toolchain
[13:29] <rsalveti> ogra_ac: to drop it you should at least test the reboot -f, that didn't work without marm
[13:29] <rsalveti> I think we should be fine with it, but would be good to test the same bug as before
[13:30] <ogra_ac> sure
[13:30] <ogra_ac> first of all i want run.init to work though
[13:30] <rsalveti> it's probably a combination with the new toolchain
[13:30] <ogra_ac> worst case jasper can pull reboot from the system in and not use the busybox one
[13:31] <rsalveti> sure, if it makes the image usable, go for it
[13:32] <ogra_ac> well, i dont count on A1 anymore anyway
[13:32] <cjwatson> you could compare assembly of run-init
[13:33] <ogra_ac> i didnt see assembly in it
[13:33] <rsalveti> would be good to build the new busybox with the older toolchain
[13:33] <rsalveti> to make sure it's related with it
[13:34] <ogra_ac> thats what i did above
[13:34] <ogra_ac> maverick toolchain and dropped -marm
[13:34] <ogra_ac> now i'm doing the same with the natty toolchain
[13:34] <rsalveti> oh, ok, I thought you just dropped -marm
[13:34] <ogra_ac> and we'll see if its -marm only
[13:34] <ogra_ac> which i doubt
[13:38] <cjwatson> ogra: I mean generated assembly from the compiler
[13:38] <cjwatson> although, you said that run-init didn't change, so I guess it's not that
[13:39] <ogra_ac> right
[13:39] <ogra_ac> klibc is the same as mavericks (not even rebuilt) as well as eglibc
[13:39] <ogra_ac> and downgrading to mavericks busybox-initramfs makes everything work fine
[13:41] <cjwatson> something to do with how it's executing subprocesses?
[13:42] <ogra_ac> likely
[13:42] <ogra_ac> run-init only calls execve() afaik
[13:42] <ogra_ac> and it seems to fail in that
[13:42] <cjwatson> or not subprocesses in this case, I hope we do 'exec run-init'
[13:43] <cjwatson> do you have anything resembling a traceback or anything like that?
[13:43] <ogra_ac> note really and its really hard to get it from the point where run-init runs since the calling pid needs to be 1
[13:43] <ogra_ac> *not
[13:44] <ogra_ac> i think NCommander managed to get an strace by hacking up /init
[13:44] <ogra_ac> but he seeem to not have attached it to the bug (and isnt up yet)
[13:44] <ogra_ac> *seems
[14:07] <ogra> GRRRR !
[14:07] <ogra> so it *IS* -marm
[14:08] <ogra> boots fine when built with natty toolchain and -marm dropped
[14:11] <ogra> uploaded
[14:11] <cjwatson> go ahead and upload it with the -marm dropped, then
[14:11] <cjwatson> ah yes :)
[14:11] <cjwatson> thanks
[14:11] <cjwatson> are you going to shoot for revalidating this in time for an alpha 1 release?
[14:11] <ogra> when is ETA for A1 ?
[14:11] <cjwatson> ASAP
[14:12] <ogra> then just skip it, i think i saw an oem-config crash too when testing (but didnt pay much attention to that one since i was only validating initrd)
[14:12] <cjwatson> Riddell: I assume you want a Kubuntu desktop rebuild as soon as this publisher run has finished?
[14:12] <ogra> so its inlikely it will survive
[14:12] <cjwatson> ogra: OK, presumably might as well do a test run to catch as much as possible now?
[14:13] <ogra> yes, but i'm not tied to release A1 if this one doesnt work
[14:14] <ogra> i know there were some ubiquity fixes (skaet said so) and i was testing yesterdays image
[14:14] <ogra> so it might well be fixed already
[14:17] <Riddell> cjwatson: yes please (assuming ubiquity is in it)
[14:17] <highvoltage> pitti: the already tested 1130 one, please
[14:17] <pitti> highvoltage: ok, thanks
[14:18] <pitti> skaet_: ^ FYI
[14:18]  * highvoltage needs to get up earlier on alpha days :)
[14:24] <highvoltage> skaet_: I added Edubuntu to https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview - ideally I would've liked to be more terse, but pretty much all I added there is important
[14:26] <cjwatson> Riddell: it is, except for armel
[14:27] <Riddell> armel is our for alpha 1 for kubuntu for sure
[14:27] <cjwatson> so can't build the preinstalled ones yet, but I assume that those suffer from the same issue as ogra's
[14:27] <ogra_ac> heh, yeah
[14:27] <cjwatson> oh yes of course, KDE is hosed there
[14:27] <ogra_ac> right
[14:27] <cjwatson> sorry, should have known that
[14:27] <ogra_ac> no QT, no KDE
[14:27] <ogra_ac> nah, its enough if Riddell and i know ;)
[14:35] <cjwatson> Riddell: rebuilding now
[14:40] <cjwatson> ogra: will you take care / have you taken care of letting management know that alpha-1 is toast on arm?
[14:47] <ogra_ac> cjwatson, i will, if skaet_ is up, david is aware that we likely wont make it
[14:48]  * skaet_ waves,   with cup of coffee in hand.
[14:48] <ogra_ac> dont wave with a cup if there is coffee in it !!!!
[14:48] <skaet_> lol
[14:48]  * skaet_ ...I've spared the keyboard this time
[14:53] <pitti> hey skaet_, good morning
[14:53] <skaet_> good afternon, pitti :)
[15:17] <skaet_> pitti,   thanks for taking care of the Edubuntu last night.  :)
[15:17] <skaet_> highvoltage,  ack - we'll release with the 20101130 ones.
[15:17] <pitti> skaet_: well, I didn't really do anything :)
[15:18] <skaet_> pitti,  it was sorted out when I woke up - that is something!!  :)
[15:49] <doko> skaet_: if you do the release announcement, would it be possible that to add that the archive will become a bit uninstallable after the alpha for a day or two, because we update the python default to 2.7?
[15:51] <skaet_> doko,  ack.   seems reasonable to add a warning.  (and good to get the python default change debugged)   might be a good idea to wait a day or two, rather than tackling it immediately on friday, since others are still trying to get their images into basic working condition.   We can talk about at release meeting tomorrow?
[15:52] <cjwatson> are there any images that expect to release late, rather than just slipping to alpha-2?
[15:52] <doko> hmm, ok, although I'd like to use the buildds on the weekend, so friday night would be good ...
[15:53] <skaet_> cjwatson, just thinking it might be nice to get a workable arm image available, before everything breaks again.
[15:53] <cjwatson> heh, somebody beat me to posting kubuntu desktop
[15:54] <cjwatson> (got distracted)
[15:54] <cjwatson> well, we can try to build one now with the fixed busybox
[15:54] <cjwatson> but ogra expected other things to be broken
[15:54] <skaet_> doko, if everyone agrees tomorrow - I'm cool with using the weekend build reseources.
[15:54]  * cjwatson runs  buildlive ubuntu-netbook daily-preinstalled && for-project ubuntu-netbook cron.daily-preinstalled
[15:54] <rsalveti> but the good thing is that the arm image will at least boot now
[15:55] <ogra_ac> well, we could test at least
[15:55] <ogra_ac> cjwatson, skaet_ ^^^
[15:55] <skaet_> ogra_ac,  ack.
[15:55] <cjwatson> you should have a build in, er, however long it takes
[15:55] <ogra_ac> but i saw an error popping up with the old oem-config/ubiquity which i didnt pay attention to (due to being busy with initrd issues)
[15:55] <ogra_ac> 90min
[15:56] <rsalveti> ouch
[15:56] <ogra_ac> but the image was a day old
[15:56] <cjwatson> don't suppose anyone has a traceback?
[15:57] <ogra_ac> nope
[15:57] <ogra_ac> i can check if there is a log on the SD, gimme a sec
[16:06] <jibel> skaet_, bug 684059 is a showstopper for kubuntu, any chance to fix it today ?
[16:06] <ogra_ac> cjwatson, http://paste.ubuntu.com/539026/
[16:06] <ubot4`> Launchpad bug 684059 in ubiquity (Ubuntu) "Kubuntu Live Session/Installer: NameError: global name 'QWidget' is not defined in /usr/lib/ubiquity/frontend/kde_components/PartAuto.py (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/684059
[16:06] <jibel> Riddell, ^ ?
[16:06] <Riddell> jibel: it's fixed
[16:08] <cjwatson> jibel: 20101202
[16:09] <jibel> cjwatson, Riddell, ok thanks.
[16:09]  * cjwatson wonders why Riddell's upload didn't close the bug
[16:10] <cjwatson> Riddell: ... you know, it's nice if you upload the same thing as is in bzr. :-)
[16:10] <cjwatson> archive logs say:
[16:10] <cjwatson> 2010-12-02 13:10:35 DEBUG     * Automatic update of included source packages: partman-auto
[16:10] <cjwatson> 2010-12-02 13:10:35 DEBUG       93ubuntu2.
[16:10] <cjwatson> bzr says:
[16:10] <cjwatson>   * ubiquity/frontend/kde_components/PartAuto.py fix namespace on QWidget
[16:10] <cjwatson>     LP: #684059
[16:11] <cjwatson> the upload has the fix, it's just the changelog that's wrong
[16:11]  * cjwatson closes the bug by hand
[16:12]  * ogra_ac wonders what /var/lib/ubiquity/apt-install-direct is
[16:14] <cjwatson> I'm fixing that bug
[16:14] <cjwatson> notice that it fails trying to *create* that file - ergo the directory doesn't exist
[16:15] <ogra_ac> ah
[16:15] <cjwatson> fixed in bzr.  want me to upload?
[16:15] <ogra_ac> and i was grepping myself to death :)
[16:15] <cjwatson> I don't know if that's the only thing
[16:15] <ogra_ac> well, at least iots one down
[16:15] <cjwatson> perhaps if you try applying that fix by hand?
[16:15] <cjwatson> r4446 in ubiquity
[16:16]  * ogra_ac checks
[16:16] <ogra_ac> grrr, need to bzr upgrade first
[16:20] <ogra_ac> sigh ... slooow
[16:26] <ogra_ac> ah, finlly
[16:26] <ogra_ac> *finally
[16:37] <pitti> good night everyone
[16:39] <skaet_> good night pitti.
[16:39] <cjwatson> sigh, arm build failed because ubiquity wasn't in sync
[16:40]  * cjwatson restarts :-/
[16:40] <ogra> yeah, just noticed that too
[16:40] <ogra> test install running btw
[16:56] <ogra> cjwatson, happily looking at a 2D netbook screen here, seems the fix is good to upload
[16:57] <rsalveti> cool
[16:57] <cjwatson> ok, good, will do
[16:58] <ogra> beyond that natty seems to run really great
[17:21] <lamont> I wonder if ppc will catch up before alpha1
[17:21] <ogra_ac> we could try building it on arm ;)
[17:22] <ogra_ac> seems to be faster
[17:22] <lamont> ubiquity was what crabapple was building when it died
[18:01] <rsalveti> ogra_ac: cjwatson: I can also confirm that the arm image worked fine after porting the busybox and ubiquity fixes
[18:01] <rsalveti> running normal desktop now
[18:02] <ogra_ac> ah, good to know
[18:29] <marjo_> ogra_ac: are you testing http://iso.qa.ubuntu.com/qatracker/test/4865
[18:30] <ogra_ac> marjo_, wont work without manually applying a ubiquity fix
[18:30] <marjo_> ogra_ac: ack
[18:31] <ogra_ac> the build before was tested, fixes for both bugs we identified were uploaded
[18:31] <marjo_> ogra_ac: ack
[18:32] <ogra_ac> given that we dont want to hold up A1 by re-rolling and re-testing another image we will skip A1 beyond what was tested and fixed
[18:32] <marjo_> ogra_ac: makes sense at this time
[18:33] <ogra_ac> we know that the dailies will work from now on, thats enough as a stop gap
[18:34] <ogra_ac> GrueMaster, do you plan to test the above image ?
[18:35] <ogra_ac> (with the manual ubiquity fix)
[18:36] <GrueMaster> Does this image have the busybox fix?
[18:38] <ogra_ac> yes, buut not the ubiquity one
[18:39] <GrueMaster> ok, pulling now.  I had thought it was built before the busybox fix was uploaded (based on earlier discussions on the other channel).
[18:39] <GrueMaster> Otherwise I would have tested it already.
[18:41] <ogra_ac> let me check, but i think its the new one
[18:41] <Riddell> skaet_, cjwatson: I'm off out for the evening, kubuntu images look good to release, I don't think we'll have any kubuntu release page done for alpha 1
[18:41] <ogra_ac> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20101202.1/ should have the fixed busybox
[18:42] <skaet_> Riddell, ok, I'll remove the refs from techoverview for the alpha1 for now.
[18:42] <GrueMaster> Ok.  The test on iso.qa points to 20101202
[18:42] <GrueMaster> and I just finished pulling it down.
[18:42] <ogra_ac> yeah, just seeing that
[18:43] <GrueMaster> Will restart zsync...again.
[18:43] <ogra_ac> well, zsync to the new one should be fast
[18:43] <ogra_ac> only a few byte have changed
[19:01] <Daviey> Can the A1 image of Mythbuntu be canned... there is unlikely to be any testing, and the non platform delta with Maverick is none.
[19:02] <cjwatson> Daviey: yes, superm1 communicated that to us
[19:03] <cjwatson> we'll skip publishing it
[19:03] <Daviey> ahh perfect, i missed that
[19:04] <skaet_> Daviey, have gone ahead and disabled it in the tracker as well to make it clear.
[19:05] <Daviey> skaet_: awesome.
[19:23] <GrueMaster> Can someone update iso.qa with the correct ubuntu netbook armel image?  It is 201011202.1 not 20101202.  I don't want to enter data then have someone kill my data because of it being updated.
[19:26] <cjwatson> I thought that that one was going to fail too, due to the lack of ubiquity 2.5.5?
[19:26] <cjwatson> but I can certainly update it - doing so now
[19:28] <cjwatson> done
[19:31] <GrueMaster> ogra_ac asked me to test it after manually modifying the image with the ubiquity patch.  It seems to be working.  BTW:  Is there a bug filed for that patch?  Need it for tracker.
[19:37] <ogra_ac> GrueMaster, just add a note about it, there was no bug since it was found and fixed immediately
[19:38] <GrueMaster> I can't pass the image as is.  System doesn't work that way.
[19:38] <ogra_ac> sure, mark it failed then, just so we have a datapoint for it
[19:38] <GrueMaster> I need a bug number for that.
[19:40] <ogra_ac> ??
[19:40] <cjwatson> file one if you have to
[19:40] <ogra_ac> just check the "failed" radiobutton and leave a note
[19:41] <cjwatson> though the fix is already uploaded so it's just pushing paper ...
[19:41] <ogra_ac> right
[19:43] <GrueMaster> I understand that it is all paperwork at this point.  I didn't design the system.  But I can't mark it as passed as the image fails without the fix, and I can't mark it as failed without a bug number.
[19:43] <GrueMaster> So, I will install ubiquity and file a proper bug report.
[19:43]  * ogra_ac tries
[19:43] <cjwatson> you don't need to install ubiquity
[19:43] <ogra_ac> wow
[19:43] <cjwatson> this doesn't need logs, it can just be a placeholder bug
[19:43] <ogra_ac> thats bad
[19:43] <ogra_ac> GrueMaster, i understand what you mean
[19:52] <GrueMaster> Bug filed and updated as Fix Committed.  iso.qa updated.  I'm breakig for lunch.  bbl.
[19:53] <highvoltage> is it out yet?
[19:53]  * highvoltage ducks
[19:53] <ogra_ac> GrueMaster, thanks a lot
[19:53] <cjwatson> GrueMaster: Fix Released
[19:53] <cjwatson> (ubiquity 2.5.5)
[19:54] <ogra_ac> GrueMaster, i will not ask you such stuff again but just strike it from the tracker in the future, that was silly (i didnt know the tracker is so bad in this regard)
[19:56] <cjwatson> never mind, I've closed it now
[19:59] <GrueMaster> ogra_ac: This is one of many issues I have with the tracker.  The biggest issue is that if we were to respin for any issue that is non-related to any test results previously posted, I can't pull them up and confirm that the status hasn't changed.
[20:00] <ogra_ac> yeah, i remember you saying that before
[20:00] <ogra_ac> do we have a project we can file bugs against ?
[20:01] <ogra_ac> would be great if there could be a link in the tracker itself to file bugs against it
[20:01] <cjwatson> ubuntu-qa-website, I think?
[20:01] <cjwatson> though best check with somebody in QA
[20:03] <marjo_> ogra_ac, cjwatson, GrueMaster: https://bugs.launchpad.net/ubuntu-qa-website/+filebug
[20:03] <ogra_ac> perfect
[20:22] <ogra_ac> GrueMaster, Bug 684404 and bug 684409 (if you want to subscribe to them)
[20:22] <ubot4`> Launchpad bug 684404 in ubuntu-qa-website "the isotracker should have a "file bug against this tool" link i its menu (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684404
[20:22] <ubot4`> Launchpad bug 684409 in ubuntu-qa-website "there should be a way to mark an iso test as failed even without a bug (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684409
[20:27] <highvoltage> w/win 26
[20:27] <ogra_ac> does the first w stand for "whash" ?
[20:31] <highvoltage> I go through channels quite fast, so I guess it must be 'warp'
[20:31] <ogra_ac> heh
[20:54] <stgraber> ogra_ac: that's a new "feature" :) I didn't implement that in the tracker, with my code you could mark a failed without a bug number
[20:55] <ogra_ac> stgraber, heh
[20:55] <marjo_> stgraber, ogra_ac: the reason we put that feature in is to be able to track "failed tests with a bug number" i would prefer we don't go backwards!
[20:56] <ogra_ac> well, for this case it cuased extra work for three people
[20:56] <ogra_ac> but i understand that its a corner case
[20:57] <marjo_> ogra_ac: understood
[20:57] <marjo_> ogra_ac "most" of the time, when a tester claims a test failure, we want to track it
[20:58] <ogra_ac> indeed
[20:58] <ogra_ac> as i said to tobin above, in the future i will just wipe the image from the tracker
[20:58] <ogra_ac> just felt more accurate to mark it properly failed with a comment
[20:59] <marjo_> ogra_ac: ack
[21:36] <cjwatson> smoser: http://uec-images.ubuntu.com/releases/natty/alpha-1/ says "Daily Build"
[21:37] <smoser> yeah. i know.
[21:37] <smoser> i'll see why
[21:37] <cjwatson> ok, hadn't seen it on this channel
[22:05] <bjf> skaet_, release schedule shows 10.04.2 as Jan 27th, is that still correct?
[22:06] <skaet_> bjf,  hmm have missed an update or two.  :)
[22:06] <skaet_> should be in Feb
[22:06] <smoser> cjwatson, fixed now. http://uec-images.ubuntu.com/server/releases/natty/alpha-1/
[22:07] <bjf> skaet_, maybe i'm looking at the wrong schedule? https://wiki.ubuntu.com/LucidReleaseSchedule
[22:08] <skaet_> That's Lucid's...
[22:08] <bjf> skaet_, and lucid is the 10.04 LTS
[22:08] <charlie-tca> bjf, https://wiki.ubuntu.com/NattyReleaseSchedule shows Feb 17
[22:09] <skaet_> I'll go in and update Lucid's if that's where folks will look
[22:09]  * skaet_ figured I'd missed a couple.
[22:09] <bjf> skaet_, it's also on: https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS
[22:09] <skaet_> bjf,  cool.  willl take care of them all right now.
[22:21] <ScottK> doko: Where did we agree to switch to Python 2.7 as default right after Alpha 1?
[22:24] <cjwatson> foundations meeting yesterday
[22:24] <cjwatson> though skaet_ asked that we wait until after the release meeting tomorrow
[22:26] <ScottK> I thought we agreed for him to do an archive rebuild test.
[22:27] <ScottK> The plan all along has to been to get 2.7 supported first.
[22:27] <ScottK> We don't even have Main done yet.
[22:35] <cjwatson> oh, I missed "as default", sorry
[22:36] <cjwatson> http://irclogs.ubuntu.com/2010/12/01/%23ubuntu-meeting.txt:[16:41] <doko> in that case, I would like to make the test rebuild with 2.7 as the default, so we know immediately what needs to be fixed
[22:36] <cjwatson> http://irclogs.ubuntu.com/2010/12/01/%23ubuntu-meeting.txt:[16:41] <barry> doko: do it
[22:36] <cjwatson> I find that ambiguous
[22:37] <cjwatson> at the time, I understood that to mean "switch the default, and immediately do a test rebuild so that we know what we need to plough through"
[23:11] <doko> cjwatson: yes, the latter is what I meant
[23:44] <ScottK> OK.
[23:44] <ScottK> Not what I understood at all.
[23:45] <ScottK> I thought that meant do a test rebuild so we'd know what needed to be done before we were ready to switch.
[23:45] <ScottK> doko, cjwatson ^^^
[23:45]  * ScottK doesn't understand the rush to break the archive?
[23:48] <cjwatson> I don't mind, as long as we're not so leisurely that 2.7 misses natty
[23:53] <doko> there is no rush. and I'll be surprised to learn how you'll avoid breakage for a short amount of time
[23:56] <ScottK> doko: Until you've done the rebuild test and we've at least got 2.7 support in packages that will support both, how do you know it will be short?
[23:57] <doko> yes, this is what was missed until now, but afaiu barry, the rebuild test was done


[00:03] <bryce> michaellarabel: btw I think you need a s/Intel/Canonical/ in the second to the last paragraph on http://www.phoronix.com/scan.php?page=article&item=ubuntu_netbook_performance&num=8
[00:03] <bryce> "As of this week, Intel is looking at fixing some of the performance problems when using EXA with Intel graphics by enabling the greedy migration heuristic by default."
[00:07] <michaellarabel> oops, yeah. Fixing now.
[02:18] <jbarnes> bryce: btw I wonder how the perf would look with my exa pixmap management patch (the one I added to freedesktop 20739)
[02:19] <bryce> jbarnes: I set up a ppa for it - https://edge.launchpad.net/~bryceharrington/+archive/blue
[02:19] <jbarnes> cool
[02:20] <bryce> jbarnes: not sure why manoj has not responded on that bug... he was in a dither about it when he first filed it, but strangely went silent the past week
[02:21] <bryce> man, I wish we had an automated phoronix set up that I could just point at a ppa or a patch, and have it automatically give results
[02:22] <jbarnes> that would be cool
[02:42] <pwnguin> Matthew Garrett is currently: angry
[02:53] <bryce> pwnguin: ??
[02:54] <pwnguin> "Seriously Intel.
[02:54] <pwnguin> http://mjg59.livejournal.com/110535.html
[02:57]  * bryce shudders at memories of psb support
[04:46] <superm1> i've got a set of patches to fix that radeon mesa bug too now. just need to narrow it down and see if they're all necessary, or if I can fix it with just one
[04:46] <superm1> (bug 341898)
[05:14] <superm1> tjaalton, bryce the patch got a basic look over from arlied in #dri-devel, so i'd like to squeeze this in if we could.  were you guys gonna make any changes to the other applied patches regarding the intel issue?
[05:15] <superm1> or were you saving those for SRUs instead
[05:15] <superm1> er s/arlied/airlied/
[05:28] <tjaalton> superm1: I'd need to read the backlog first :) but yes, I'd be ok with that patch
[05:28] <tjaalton> and editing .git/config should be enough to allow pushing
[05:29] <superm1> yeah finally got it pushed earlier
[05:29] <tjaalton> change the url to ssh+git://foo-guest@
[05:29] <superm1> i just ended up doing ssh://foo-guest@, didn't realize ssh+git:// was a protocol
[05:29] <tjaalton> ah, both should work
[05:30] <tjaalton> just noticed that I had that
[05:30] <superm1> so are you guys doing any other intel deltas to mesa that should go in this same upload, or just treat them mutually exclusive?
[05:30] <tjaalton> I'm not sure, bryce?
[05:30] <tjaalton> it probably doesn't matter if there's one more upload
[05:31] <superm1> okay.
[05:32] <superm1> so hopefully i don't need to touch mesa for a long time now, debugging these has been very difficult :)
[05:42] <tjaalton> here's hoping ;)
[08:14] <bryce_> superm1, tjaalton: I'd also be okay with dropping 103 in mesa
[08:14] <tjaalton> bryce_: cool
[08:15] <tjaalton> I think I'll ask my boss (and wife) if there's a chance to get to the UDS..
[08:16] <bryce_> what it gains is not something that was available in intrepid, thus is not a regression.  And if it eliminates even just some of the freezes, it's a win
[08:16] <tjaalton> yeah
[08:16] <bryce_> tjaalton: that would be great if you can come!  Did you get on the sponsorship list?
[08:17] <tjaalton> bryce_: no, but I think my boss could send me.. that way I wouldn't have to spend my holidays to get there
[08:18] <bryce_> ah good
[08:18] <tjaalton> we are moving in two weeks, so we should be settled a month from now
[08:20] <tjaalton> +down
[08:23] <tjaalton> the specs are just too interesting to miss ;)
[08:24] <bryce_> :-)
[08:24] <bryce_> yeah I got some presentations to write
[08:24] <bryce_> oh hell what is the cat up to
[08:24] <bryce_> brb
[08:24] <tjaalton> :)
[08:28] <bryce_> left the cupboard where we keep the TP open
[08:28] <bryce_> apparently toilet paper roll wrappers make a nice crinkley sound when you sink your claws into them...
[08:30] <bryce_> anyway, I got sick of debugging the freeze bugs blindly.    We already have the 2.6.30-rc2 kernel so the hard part's done
[08:31] <tjaalton> heh
[08:32] <tjaalton> yep, it's really frustrating..
[11:09] <Mirv> my i965 is btw GMA X3100 (mobile GM965), if interested. indeed with the max texture size jaunty seems now rock stable even on heavy duty (like compiling and installing ubuntu in virtualbox at the same time, while spinning the cube and browsing the web)
[11:09] <Mirv> again I missed some words, "with the max texture size patch disabled" I meant
[11:30] <bryce_> what's the max texture size in your case?
[11:35] <tjaalton> read the second comment too :)
[14:55] <cwillu> are i815's running xaa by default?  (i.e., with an empty xorg.conf, they're running xaa?)
[15:27] <jcristau> cwillu: probably yeah
[17:16] <bryce> tjaalton: btw what's the status on the mesa upload with 103 disabled?
[19:01] <tjaalton> bryce: it was discussed on #u-d a couple of hours ago, but I don't know how it ended :)
[19:01] <tjaalton> just got back
[19:01] <tjaalton> bbiab ->
[19:12] <bryce> tjaalton: ok I've committed the change and will upload it at this time
[19:18] <tjaalton> bryce: great, thanks
[19:18] <tjaalton> bryce: I wonder if it's patch 104 giving you the trouble?
[19:18] <tjaalton> but not Mirv or me
[19:18] <bryce> tjaalton: jesse also pointed me at https://bugs.freedesktop.org/show_bug.cgi?id=20704
[19:18] <tjaalton> it _shoudln't_ matter if exa is used, but who knows
[19:19] <tjaalton> oh
[19:20] <tjaalton> sounds like fun, I'll try it..
[19:22] <tjaalton> heh, I could use my laptop as an instrument
[19:23] <tjaalton> there's this high pitch squeak with glxgears running, and the pitch changes with the size of the window
[19:23] <tjaalton> the larger it is, the lower the pitch
[19:24] <jbarnes> ouch sounds like one of your input gains might be turned up too high?
[19:24] <bryce> hehe
[19:24] <tjaalton> it's not coming from the speaker :)
[19:24] <jbarnes> ooh
[19:25] <tjaalton> with nice tremolo
[19:25] <tjaalton> actually more like a vibrato :)
[19:26] <tjaalton> it's leaking memory, but not that much
[19:28] <tjaalton> plugged the charger and now the sound is gone :(
[19:29] <tjaalton> I need a new battery
[19:30] <bryce> buzzing battery doesn't sound good
[19:30] <tjaalton> yeah, it's broken alright
[19:31] <tjaalton> when I log in I get a popup saying that the charge is 48% and that it means the battery is likely broken
[19:31] <tjaalton> it's been acting weird for some weeks now
[19:34] <mdz> howdy folks
[19:35] <bryce> heya mdz
[19:36] <jbarnes> ooh "installation complete" on my shiny new jaunty install
[19:36] <mdz> bryce: I'm now on my affected laptop
[19:41] <mdz> bryce,jbarnes: I saw mvo's comment on the bug that PCI ID 8086:2a02 may be a common thread
[19:42] <mdz> that matches what I have as well
[19:42] <mdz> I'm not sure if that just means "GM965" or if it's more specific
[19:42] <mdz> it looks like there are only two PCI IDs with that name
[19:43] <jcristau> #define PCI_CHIP_I965_GM        0x2A02
[19:44] <jbarnes> yeah 2a02 is 965GM
[19:44] <mdz> bryce: would my time be better spent testing rolling back that mesa patch, or on trying to find a reproducer?
[19:45] <jbarnes> I'd say reproduce first, otherwise you won't know if the rollback works
[19:47] <seb128> I'm using 00:02.0 0300: 8086:2a02 (rev 0c) and I've no hang freeze and speed issue
[19:47] <jbarnes> seb128: with or without the mesa patch?
[19:47] <seb128> and I'm using this box full time with compiz one
[19:47] <seb128> stock jaunty
[19:48] <seb128> no xorg.conf change (out of virtual for multi screen)
[19:50] <bryce> mdz: yes, start by verifying you have the issue
[19:50] <bryce> vs. having seb's luck
[19:51] <mvo> seb128: and you switch workspaces a lot :)
[19:51] <mvo> seb128: rev c as well, just like the bug reporter ...
[19:51] <seb128> mvo: yes, I've my mailed full screen on one screen and IRC on an another screen, I think I switched several time by minute all day long
[19:51] <seb128> mailed -> mailer
[19:52] <seb128> I always switch using the keyboard shortcuts if that makes any difference
[19:52] <bryce> for me, it reproduced mostly with doing alt-tab
[19:53] <mdz-mini> I've been aqble to recproduce the bug with only a minute or so of tinkering
[19:53] <mdz-mini> well, a freeze anyway
[19:55] <rickspencer3> mdz-mini: do you have steps?
[19:55] <bryce> mdz-mini: wow, excellent
[19:55] <mvo> mdz-mini: on your t61?
[19:56] <bryce> mdz-mini: check that you can ssh into the machine and check your syslog to rule out just a kernel bug
[19:56] <mdz-mini> mvo, yes
[19:56] <mdz-mini> bryce, yes I can
[19:56] <bryce> ok good, so chances are high you've got this issue
[19:56] <mdz-mini> rickspencer3, I played a movie on workspace #4 then switched from workspace 1 to 5 and back many times
[19:57]  * rickspencer3 tries
[19:57] <jbarnes> ah a movie
[19:57] <rickspencer3> mdz-mini: what format moving?
[19:57] <rickspencer3> movie I mean
[19:57] <mdz-mini> rickspencer3, happened to be an mp4, but this happened with DVD as well
[19:57] <mdz-mini> I used totem
[19:57] <mdz-mini> totem-xine
[19:57] <rickspencer3> k
[19:58] <mdz-mini> I have a shell on the machine
[19:58] <mdz-mini> nothing in dmesg
[19:58] <mdz-mini> nothing in Xorg.0.log
[19:59] <mdz-mini> X server backtrace:
[19:59] <mdz-mini> #0  0x00007f2522cdbcd7 in ioctl () from /lib/libc.so.6
[19:59] <mdz-mini> #1  0x00007f2520c493bd in drm_intel_gem_bo_start_gtt_access () from /usr/lib/libdrm_intel.so.1
[19:59] <mdz-mini> #2  0x00007f251003a241 in intelFinish () from /usr/lib/dri/i965_dri.so
[19:59] <mdz-mini> #3  0x00007f2521948ac6 in __glXDisp_SwapBuffers (cl=0xac8d530, pc=<value optimized out>) at ../../glx/glxcmds.c:1425
[19:59] <mdz-mini> #4  0x00007f252194bde2 in __glXDispatch (client=0xac8e120) at ../../glx/glxext.c:523
[19:59] <mdz-mini> #5  0x000000000044e304 in Dispatch () at ../../dix/dispatch.c:437
[19:59] <mdz-mini> #6  0x0000000000433d8d in main (argc=10, argv=0x7fff2d101828, envp=<value optimized out>) at ../../dix/main.c:397
[19:59] <bryce> is that after trying to kill X or sysrq or something?
[20:00] <mdz-mini> no
[20:00] <mdz-mini> haven't touched it
[20:00] <bryce> hmm, anyway, drm_intel_gem_bo_start_gtt_access has been associated with the freeze bug, so that's not unexpected
[20:00] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/327844
[20:01] <bryce> although this is one of those cases where the symptoms aren't an exact match for the "traditional" bug
[20:01] <mdz-mini> this is one I'm confident I can reproduce
[20:02] <rickspencer3-afk> I'm running two movies now, and can't freeze my 'puer
[20:02] <rickspencer3-afk> I'm going to run rotate forever for a while
[20:02] <mvo> hm, different pci id for this one: 8086:2e22
[20:06] <jbarnes> hm I still don't see it even with movies
[20:07] <mdz-mini> strace shows it looping with:
[20:07] <mdz-mini> ioctl(12, 0x400c645f, 0x7fff2d1015b0)   = ? ERESTARTSYS (To be restarted)
[20:07] <mdz-mini> --- SIGALRM (Alarm clock) @ 0 (0) ---
[20:07] <bryce> oh speaking of strace
[20:07] <bryce> there's another insta-freeze bug if you run 'strace alarm-clock'
[20:07] <bryce> but it goes away if you pkill alarm-clock
[20:08] <bryce> supposedly, ditto strace firefox, although I couldn't reproduce that one
[20:09] <mdz-mini> rebooting, will try again with more debug symbols
[20:09] <mdz-mini> bryce, /topic in this channel is stale ;-)
[20:09] <bryce> hehe
[20:09] <mdz-mini> I happen to be using an external lcd display
[20:10] <mdz-mini> significantly larger pixel-wise than the built-in one
[20:10] <mdz-mini> so working the gpu a bit harder I suppose
[20:10] <bryce> mdz-mini: mirrored or extended?
[20:11] <mdz-mini> bryce, I turn off the buil-in
[20:11] <mdz-mini> built-in
[20:11] <bryce> ok
[20:11] <jbarnes> what resolution is the external monitor?
[20:11] <mdz-mini> I'm going to try to reproduce on the built-in display to see if that's a factor
[20:11] <mdz-mini> jbarnes, 1920x1200
[20:11] <bryce> well, patch 103 involves desktop size, so it could fit our theory
[20:12] <jbarnes> I was also thinking of the infamous pipe underrun
[20:13] <jbarnes> the debugging for that has unfortunately been removed (it was incompatible with kernel interrupt handling)
[20:23] <bryce> humm
[20:23] <mdz-mini> after a cold boot, I'm having trouble reproducing
[20:23] <bryce> tjaalton, superm1: I'm seeing something funky in the mesa git tree
[20:23] <jbarnes> I'm spinning a patch for pipe underrun debugging now
[20:23] <tjaalton> bryce: shoot
[20:24] <jbarnes> bryce: what do you see?
[20:24] <bryce> tjaalton, superm1: when I do a debuild from in the git tree, I get different results than if I do a debuild off of apt-get source mesa
[20:24] <bryce>  .gitattributes         |    4 ++++
[20:24] <bryce>  debian/changelog       |    8 ++++++++
[20:24] <bryce>  debian/patches/series  |    2 +-
[20:24] <bryce>  progs/demos/extfuncs.h |   15 +++++++++++++++
[20:24] <bryce>  progs/glsl/readtex.h   |   26 --------------------------
[20:24] <bryce>  5 files changed, 28 insertions(+), 27 deletions(-)
[20:24] <bryce> the .gitattributes progs/demos/extfuncs.h and progs/glsl/readtex.h are mystery changes
[20:25] <bryce> I can't see evidence of them in recent git changes though
[20:25] <tjaalton> from a debdiff?
[20:26] <bryce> I decided to do my mesa patch off of the apt-get source mesa, so our upload is clean
[20:27] <bryce> the extfuncs.h change seems to be adding some glVertexAttrib1fv_func variables
[20:27] <bryce> the readtex.h change appears to be deleting that header entirely
[20:28] <bryce> git says my tree is clean though...
[20:28] <tjaalton> but where is that diffstat from?
[20:28] <jcristau> readtex.h doesn't exist in git afaict. and never has
[20:28] <bryce> tjaalton: I did an apt-get source mesa, which gave me a 0ubuntu2 dsc
[20:29] <jbarnes> stuff in progs/demos shouldn't matter, they're just test programs
[20:29] <bryce> tjaalton: I committed my changes to disable patch 103, then did a debuild -S to produce a 0ubuntu3
[20:29] <bryce> then I debdiff'd those two and got the above
[20:29] <bryce> jbarnes: yeah I know, this is totally innocuous, however it worries me that there is any discrepancy at all
[20:29] <jbarnes> yeah it's a bit weird
[20:29] <bryce> jbarnes: likely it's just my crappy git skillz
[20:30] <jcristau> progs/demos/extfuncs.h is in the tarball but not in git afaict
[20:30] <tjaalton> jcristau: hmm, seems to be in my copy
[20:31] <tjaalton> of the git tree
[20:31] <jcristau> tjaalton: hrm.
[20:31] <tjaalton> but not known by git
[20:31] <tjaalton> so this might be due to _my_ sucky git fu :)
[20:31] <bryce> tjaalton: btw there was also a patch 05 (not in series though)
[20:32] <tjaalton> bryce: that I can't see :)
[20:32] <bryce> ok, that one probably was me then :-)
[20:32] <jcristau> i usually do 'git clean -dnx' to see if my working copy has changes wrt git
[20:32] <tjaalton> hehe
[20:32] <tjaalton> Would remove lib/
[20:32] <tjaalton> Would remove patches/
[20:32] <tjaalton> Would remove progs/demos/extfuncs.h
[20:32] <tjaalton> Would remove progs/glsl/readtex.c
[20:32] <tjaalton> Would remove progs/glsl/readtex.h
[20:32] <tjaalton> Would remove src/glx/x11/depend
[20:32] <tjaalton> wtf
[20:33] <bryce> oops :-)
[20:33] <bryce> git clean -dnx  looks clean in my copy
[20:33] <jbarnes> still haven't seen it on my 965
[20:33] <superm1> i try to always look at git status before i do a commit and git diff just to make sure i'm only committing what i want to
[20:33] <bryce> never heard of git clean before
[20:34] <jbarnes> mdz-mini: any luck reproducing?
[20:34]  * bryce appends to "git commands and options to know"
[20:34] <tjaalton> superm1: did you upload 0u2 based on 0u1 or the git tree?
[20:35] <tjaalton> I suspect the former
[20:35] <mdz-mini> jbarnes, not since the cold boot. still trying
[20:35] <superm1> tjaalton, i apt-get source'd mesa, added my patches, and then added the same patches to the git tree
[20:35] <superm1> so yeah the former; was that wrong to do?
[20:35] <tjaalton> superm1: well, more work for you :) (but it confirmed that it's my tree that's buggy)
[20:37] <superm1> i also generally do a debdiff between dsc's for packages i've not worked with before to make sure their build systems and/or vcs' aren't injecting new stuff that i dont expect in the debdiff
[20:38] <mdz-mini> is there any reason to suspect it's related to suspent/resume?
[20:38] <mdz-mini> that would explain why it occurs infrequently for some
[20:39] <bryce> the apr 3rd freeze has not been definitively associated with suspend/resume
[20:39] <bryce> however there have definitely been reports about X freeze issues relating to resume
[20:39] <tjaalton> mine dies if I've booted attached to the dock
[20:40] <mdz-mini> it seems to need to be in a certain state, but I'm not sure how to get it there
[20:40] <mdz-mini> when I woke it up after being suspended all day, it was easy
[20:40] <bryce> mdz-mini: if jesse's right, it might be a memory issue
[20:41] <bryce> so either a memory region has to fill, or has to get filled with the right combination of stuff
[20:41] <mdz-mini> jbarnes, is there an easy way to get the X server to allocate lots of chunks of memory?
[20:41] <tjaalton> I have four gigs, so it could well be hard for me to reproduce
[20:41] <jbarnes> suspend/resume could definitely change global chip state that we don't restore
[20:41] <jcristau> tjaalton: boot with mem=1G? :)
[20:41] <tjaalton> btw; 20:50 < agd5f> r6xx/r7xx 3D driver pushed
[20:41] <jbarnes> mdz-mini: running lots of GL apps pounds the memory manager pretty hard
[20:41] <jbarnes> or stuff like openarena or other big apps
[20:42] <tjaalton> jcristau: good idea, and actually only 3G is available anyway :)
[20:43] <tjaalton> it has leaked 200meg so far, in 2h
[20:44] <tjaalton> there, no swap
[20:45] <jbarnes> oops suspend/resume failed... seems to have crashed my X server (had a video playing)
[20:45] <bryce> tjaalton: sweet
[20:45] <mdz-mini> ok I just reproduced again
[20:46] <bryce> ok, I'm going to go snag some lunch, then work on the freeze debug tool packaging.  be back shortly
[20:46] <jbarnes> ah no wait X is up, but hung
[20:46] <jbarnes> yep in start_gtt
[20:46] <jbarnes> right after resuming
[20:46] <rickspencer3> So I just ran the rotate forever script with 100ms sleep with three movies running on three desktops
[20:46] <mdz-mini> different stack trace
[20:47] <rickspencer3> 25 minutes later, the system is working fine
[20:47] <mdz-mini> jbarnes, we have a different bug# for that
[20:47] <mdz-mini> I think
[20:47] <mdz-mini> for a freeze directly after resume
[20:48] <mdz-mini> latest stack trace
[20:48] <mdz-mini> http://pastebin.ubuntu.com/153009/
[20:48] <Mirv> we would almost need a table about who is trying what on which chipset and which driver
[20:49] <Mirv> but at least I can fairly surely say the ~bug359392 packages from PPA work as well as did my own build without the max texture patch. used for 10 hours and now having the rotate script running
[20:50] <tjaalton> Mirv: do you have plenty of RAM?
[20:50] <Mirv> tjaalton: 2 gigs
[20:50] <tjaalton> pretty standard these days I guess
[20:50] <mdz-mini> jbarnes, what sort of info might I be able to get from it while it's hung?  do you want a login?
[20:51] <jbarnes> reg dump
[20:51] <jbarnes> or if you have the kernel package & gpu tools package you could get a batchbuffer dump
[20:51] <mdz-mini> jbarnes, regdump: http://pastebin.com/f38c68b88
[20:52] <jbarnes> mdz-mini: so did you have to suspend/resume to reproduce it?  or just plug in the external monitor?
[20:53] <mdz-mini> jbarnes, when I had trouble reproducing, I tried suspend/resume a few times, then launching more apps, then adding some glxgears instances
[20:53] <jbarnes> ok so at least one suspend/resume was required...
[20:54] <mdz-mini> the setup when it finally froze was video + browser + 2xglxgears + terminal all on separate desktops
[20:54] <mdz-mini> after a few suspend/resume cycles
[20:55] <mdz-mini> not sure which elements were essential
[20:56] <mdz-mini> if I could get it unwedged it would be interesting to try again with the same instance of the server
[20:56]  * rickspencer3 tries suspend/resume then repro
[20:57] <mdz-mini> jbarnes, bryce is it more useful for me to keep trying to distill this down to a simpler reproducer or to try to analyze the frozen state?
[20:59] <jbarnes> the register dumps didn't have anything interesting that I could see
[20:59] <jbarnes> w/o the kernel patches I'm not sure there's much else we can grab unless dmesg has an oops or something
[21:00] <mdz-mini> no such luck
[21:01] <jbarnes> if you can reproduce it fairly easily (maybe try a few more times) then you could start bisecting
[21:01] <mdz-mini> i915_wait_irq                                      /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
[21:01] <mdz-mini> (wchan)
[21:01] <jbarnes> yeah it's just waiting for some rendering to finish
[21:01] <jbarnes> cool mine hung in suspend this time
[21:02] <jbarnes> totally wedged
[21:02] <jbarnes> ug
[21:03] <Mirv> with the PPA mesa, I'm (i965 2a02, 2GB RAM) now running successfully rotate-forever with Flight Gear, full screen looping video, firefox and two glxgears while doing suspend-resume-cycles. I guess I could try with mem=1G and see if I get it to hang.
[21:04] <mdz-mini> Mirv, I think we're talking graphics memory here rather than main memory
[21:06] <Mirv> mdz-mini: well, I guess intel allocates it from the main memory relative to its size, as it does not have own integrated memory usually
[21:06] <jbarnes> yeah gem allocates from main memory
[21:06] <jbarnes> and swaps stuff in and out of the graphics mapping
[21:07] <bryce> mdz-mini: boiling down the steps to reproduce would be the most helpful
[21:07] <mdz-mini> bryce, ok, I'll start working on a script
[21:07] <Mirv> bryce: did you btw have a) amd64 b) less than 2GB of RAM? and 2a02?
[21:07] <bryce> mdz-mini: at some point I'll want you to also put on the 2.6.30-rc2 kernel and verify you can still reproduce it there, since the debug tools have to be run on that kernel
[21:08] <bryce> Linux salisbury 2.6.28-11-generic #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009 i686 GNU/Linux
[21:08] <bryce> MemTotal:        1534756 kB
[21:09] <bryce> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
[21:09] <bryce> 	Subsystem: Dell Device [1028:01f3]
[21:09] <mdz-mini> jbarnes, doesn't it allocate a fixed chunk regardless of how much main memroy there is? or am I confused?
[21:09] <jbarnes> mdz-mini: no not anymore... with GEM it's all dynamic
[21:10] <mdz-mini> fun
[21:11] <bryce> jbarnes: btw fyi, gpu tools which don't need to be run as root, we can add to apport (our automatic bug reporting script)
[21:11] <jbarnes> cool
[21:11] <Mirv> bryce: ok, I was just guessing if somehow dropping 103 only helped amd64 users, but I've yet to check if tjaalton is also running amd64
[21:11] <jbarnes> I'd guess the big ones need root though, since they access debugfs files
[21:11] <bryce> jbarnes: intel_reg_dump unfortunately appears to need root, which is why we aren't including captures of that for all bug reports (tho would be nice if we could)
[21:12] <tjaalton> Mirv: 32bit
[21:12] <Mirv> tjaalton: ok, not a factor then. less than 2GB memory?
[21:13] <tjaalton> Mirv: no, 3
[21:13] <jbarnes> mdz-mini: another thing to check would be to see if you're still getting gfx interrupts after the hang
[21:13] <jbarnes> grep i915 /proc/interrupts
[21:13] <Mirv> tjaalton: ok, some magic then might be in having less than 2GB memory, but otherwise there is nothing in common
[21:16] <tjaalton> Mirv: I'll boot with mem=1G so we'll see what happens
[21:24] <mdz-mini> jbarnes, will check that next time
[21:31] <jbarnes> I might just have seen it too
[21:31] <jbarnes> I was idle though after a resume
[21:31] <jbarnes> no more interrupts
[21:31] <jbarnes> I wonder if pci=nomsi will help
[21:32] <jbarnes> also the render clock gating reg looks busted
[21:37] <bryce> mdz-mini: also at some point you'll want to test the mesa upload I just did, to see if your freeze is one that is fixed by dropping this patch 103
[21:37] <bryce> I think it's still in the approval queue atm
[21:38] <mdz-mini> hasn't frozen yet but it rendering very slow
[21:39] <mdz-mini> came back to normal after a while
[21:39] <jbarnes> mdz-mini: your last reg dump was from after the hang right?
[21:39] <mdz-mini> jbarnes, correct
[21:39] <bryce> mdz-mini: does the slowness increase over time or is it constantly slow?
[21:39] <mdz-mini> bryce, it gow slow and then nirmal again
[21:39] <mdz-mini> got
[21:40] <mdz-mini> jbarnes, I ran the reg dumper twice, that was the second run in cast that matters
[21:40] <jbarnes> ok
[21:40] <jbarnes> shouldn't matter
[21:40] <mdz-mini> this mini 9 keyboard is awful
[21:43]  * bryce is curious if the mini 12 kbd is better
[21:45] <mdz-mini> I wonder if the vt switch on suspend/resume is a factor
[21:45] <mdz-mini> hmmm
[21:45] <jbarnes> mdz-mini: could be... if you can reproduce it across vt switch rather than suspend/resume it would mean the bug probably isn't due to lost chip state
[21:46] <mdz-mini> I ran my repro script for 10 minutes without a crash
[21:46] <mdz-mini> then suspended and resumed
[21:46] <mdz-mini> ran it again
[21:46] <mdz-mini> and it crashed after 10 seconds
[21:47] <mdz-mini> backtrace the same as last time
[21:47] <mdz-mini> no i915 interrupts
[21:48] <mdz-mini> jbarnes, anything else I should look at?  next I'll reboot and try with a vt switch
[21:48] <jbarnes> does grep i915 /proc/interrupt show that it's MSI
[21:48] <mdz-mini> 2295:     449673     415505   PCI-MSI-edge      i915@pci:0000:00:02.0
[21:48] <jbarnes> ok yeah try with vt switch
[21:50] <seb128> mdz-mini: what do you do exactly to trigger it?
[21:50] <mdz-mini> seb128, I'll post the script
[21:50] <seb128> I've tried with video playing, glxgear, workspace switching, alt-tab, suspend resume, no such issue there
[21:51] <seb128> same PCI-MSI-edge on my config
[21:51] <seb128> mdz-mini: thanks
[21:51] <mdz-mini> it just start some apps and switches workspaces
[21:51] <mdz-mini> starts
[21:51] <seb128> ok, I guess there is something else than the video chipset needed there
[21:52] <seb128> I've been using this box full day for the week and never ran into the issue, so I don't think those actions will trigger it now
[21:54] <mdz-mini> jbarnes, vt switch did not seem to trigger it, tried twice
[21:55] <mdz-mini> suspend/resume seemed to do it
[21:55] <jbarnes> ok
[21:55] <jbarnes> care to try pci=nomsi
[21:55] <jbarnes> btw what was the irq count on the last hagn?
[21:55] <jbarnes> hgn?
[21:55] <jbarnes> hang
[21:55] <mdz-mini> 2295:      52909      53155   PCI-MSI-edge      i915@pci:0000:00:02.0
[21:56] <mdz-mini> I'm going to add a suspend to the script, confirm that works after a warm boot, then if it's reliable i'll try nomsi
[21:56] <jbarnes> sounds good
[22:10] <mdz-mini> no joy
[22:11] <jbarnes> nomsi didn't help?
[22:11] <mdz-mini> no, reproducer isn't reliable enough yet to test
[22:11] <jbarnes> yuck
[22:11] <jbarnes> I'm putting together a kernel patch to give us some additional debug info too
[22:12] <mdz-mini> ok
[22:13] <bryce> btw, the 2.6.30-rc2 kernel is at http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/
[22:13] <jbarnes> has anyone been able to reproduce with a more recent kernel?
[22:13] <bryce> (I'd love to chunk that into a proper ppa if anyone has a clue on how to do that)
[22:19] <mdz-mini> bryce, what's stopping you from just uploading it?
[22:20] <mdz-mini> I'm completely failing to reproduce anymore
[22:20] <tjaalton> no source package for mailine builds
[22:20] <tjaalton> +n
[22:21] <mdz-mini> hmm, ask the kernel team. surely they generate one and just don't publish it yet
[22:22] <bryce> heisenfreeze
[22:23] <bryce> reproducibility is inversely proportionate to the availability of means to debug
[22:28]  * albert23 has the compiz freeze with 2.6.30-rc2
[22:29] <albert23> intel_reg_dump: http://paste.ubuntu.com/153058/
[22:29] <albert23> intel_gpu_dump that is
[22:30] <mdz-mini> just got it again
[22:30] <mdz-mini> after some random number of tries with the script
[22:31] <bryce> hrm, this intel-gpu-tools package appears to need libdrm 2.4.6... >just< newer than we have in jaunty
[22:32] <bryce> jbarnes: is this going to work if I force it to build against libdrm 2.4.5 or do I really truly need .6?
[22:32] <jbarnes> bryce: just make sure you skip 2.4.7 and go to 2.4.9
[22:34] <bryce> erm, the problem is more one of packaging for use with jaunty...
[22:34] <bryce> either I need to get the tool to build against the libdrm we have, or I need to package up a newer libdrm as well
[22:34] <jbarnes> I'm not sure what it requires
[22:34] <jcristau> getting the packages from sid would probably work, if this is for debugging?
[22:35] <bryce> jcristau: sort of; I'm trying to get this packaged for other ubuntu-ers to use
[22:36] <jcristau> then maybe putting the sid packages into a ppa?
[22:36] <bryce> yeah maybe
[22:36] <bryce> jcristau: do you have intel-gpu-tools already packaged?
[22:37] <jcristau> not yet
[22:37] <bryce> guess I should have asked that before I started...
[22:37] <jcristau> was considering replying to cworth to ask for a tarball release actually :)
[22:37] <bryce> yeah that'd be nice
[22:37] <tjaalton> I can't seem to be able to exhaust the RAM even without swap and mem=1G
[22:38] <jcristau> anyway, week end now. good luck with the debugging.
[22:39] <bryce> cya jcristau
[22:39] <bryce> ok, guess I'll snag the debian libdrm into the ppa, then toss intel-gpu-tools in there and cross my fingers that it builds
[22:40] <tjaalton> so now dustin has the same laptop as I do, and he's seeing the freezes..
[22:41] <mdz-mini> bryce, script emailed
[22:41] <mdz-mini> not reliable but it's the best I have so far
[22:42] <bryce> ok thanks
[22:49] <mdz-mini> rickspencer3 just called saying the script reproduced the problem for him, first time
[22:51] <jbarnes> I just posted a patch to the launchpad page that might dump some additional info
[22:52] <jbarnes> (assuming we're getting an error interrupt)
[22:53] <mdz-mini> I'll see if we can get a module built for our stock kernelwith the patch
[22:54] <jbarnes> I hope it patches in ok... upstream has kms while 2.6.28 doesn't
[22:54] <albert23> jbarnes: Did you see my intel_gpu_dump for the freeze? http://paste.ubuntu.com/153058/
[22:54] <jbarnes> albert23: yeah was checking it out with anholt
[22:56] <albert23> jbarnes: do you need anything else from the debugfs?
[22:56] <jbarnes> albert23: yeah the other files would be good to have too
[22:56] <jbarnes> i915_gem_active
[22:57] <jbarnes> there are quite a few, but many are probably empty
[22:57] <albert23> jbarnes: and some seem to be locked
[22:57] <bryce> mdz-mini: sweet
[22:58] <mdz-mini> bryce, where can I get intel_gpu_dump?
[22:58] <bryce> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
[22:58] <bryce> mdz-mini: unfortunately it has a deps on a newer libdrm, so am working on that presently
[22:59] <bryce> meantime you can snag it from debian
[22:59] <mdz-mini> bryce, how about a atatic amd64 binary?
[22:59] <mdz-mini> static, even
[22:59] <bryce> I can't build it in my regular build environment due to the libdrm dep, but am hoping the ppa can do it
[23:02] <bryce> ok, theoretically the tools are there now -- https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test/
[23:02] <bryce> but we'll have to wait for ppa to get them all built
[23:03] <bryce> next... sussing out kernel source packages...
[23:05] <mdz-mini> nxvl says the repro script locked his system up tight (no ssh)
[23:06] <jbarnes> mdz-mini: can you send me the script<EMAIL_ADDRESS>[23:08] <mdz-mini> jbarnes, it's attached to the bug, but sure, I'll send a copy
[23:08] <jbarnes> oh I didn't see it, I'll grab it from there
[23:08] <mdz-mini> sent
[23:09] <mdz-mini> it needs to run under compiz, requires that wmctrl is installed, and needs a 1x6 workspace layout
[23:10] <albert23> jbarnes: I have added the files to the LP bug
[23:10] <jbarnes> albert23: cool thanks
[23:10] <bryce> albert23: ooh good idea
[23:10] <bryce> jbarnes: maybe you can adapt that into something that could be included in intel-gpu-tools
[23:11] <jbarnes> yeah cworth and anholt are rapidly improving the tools
[23:11] <jbarnes> I think the reg dumper will move there soon too
[23:11] <bryce> jbarnes: it is rather ubuntu-centric at the moment but could probably be adapted without too much work
[23:11] <bryce> sweet
[23:11] <jbarnes> one day we'll even get chip reset right I hope, which will make these types of hangs a little less fatal
[23:14] <jbarnes> ugg... "make install" from a kernel tree still doesn't build an initramfs for me, nor does it update grub
[23:14] <bryce> jbarnes: shall I also stick your -intel underrun patch into this PPA, or would you prefer to keep this separate from the regular testing?
[23:14] <jbarnes> better keep that one out
[23:15] <bryce> ok
[23:19] <mdz-mini> albert23, your stack trace matches (one of) mine
[23:25] <jbarnes> geez I can't even login now
[23:25] <jbarnes> after updating to the latest bits
[23:26] <mdz-mini> jbarnes, ??
[23:26] <jbarnes> hangs the machine while playing the login sound
[23:26] <mdz-mini> are you using ext4 or anyything crazy like that?
[23:27] <jbarnes> nope
[23:28] <jbarnes> that's with my test kernel though
[23:28] <jbarnes> I could very well have broken something
[23:30] <mdz-mini> jbarnes, I've noticed that when it's wedged, sometimes I can do a clean reboot, sometimes it hangs up on the way down and only responds to sysrx
[23:30] <mdz-mini> sysrq even
[23:32] <jbarnes> aha!
[23:33] <mdz-mini> rickspencer3 reports that repro.sh froze his system without a suspend/resume
[23:33] <jbarnes> [drm:i915_driver_irq_handler] *ERROR* render error detected, EIR: 0x00000001
[23:33] <jbarnes> [drm:i915_driver_irq_handler] *ERROR* instruction error: 0x00000001
[23:33] <mdz-mini> jbarnes, is that your new debug?
[23:33] <jbarnes> yeah
[23:33] <mdz-mini> woo
[23:33] <bryce> instruction 1 eh?
[23:33] <jbarnes> that's the instruction error reg
[23:33] <jbarnes> now to lookup what that means :)
[23:34] <jbarnes> oh well that's not very useful it gave me a reserved value
[23:34] <bryce> reserved value?
[23:35] <jbarnes> the low 3 bits indicate the ring the instruction came from
[23:35] <jbarnes> values of 1-7 are marked "reserved"
[23:36] <jbarnes> could be a doc error of course
[23:36]  * jbarnes updates his patch to get more info
[23:36] <jbarnes> fwiw netconsole helped out here
[23:37] <jbarnes> the machine hard hung but I got quite a few messages anyway (even though my ssh sessions were dead)
[23:37] <mdz-mini> i have always been able to ssh in, though there are some reports similar to yours
[23:50] <bryce> yay!  finally intel-gpu-tools has built debs:  https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
[23:50] <bryce> jbarnes: also, I've stuck the underrun patch here:  https://edge.launchpad.net/~bryceharrington/+archive/green
[23:51] <bryce> jbarnes: I'm not certain that the underrun patch is appropriate for 311895 or not; if not, if you could suggest a better bug it would be useful for, I'll update the name
[23:54] <jbarnes> bryce: well it sounds like that bug already has output from when the debug code was in
[23:54] <jbarnes> so we know it's an underrun
[23:54] <bryce> right... is there a more appropriate bug to use this patch with?
[23:56] <jbarnes> bryce: have you ever seen the type of jitter underruns cause?
[23:56]  * jbarnes digs up a video
[23:56] <mdz> bryce: so I can't use intel-gpu-tools without upgrading libdrm2, which is part of the stack that we're inspecting right?
[23:57] <bryce> mdz, correct - also need 2.6.30-rc2
[23:57] <jbarnes> anything that looks like this https://bugs.freedesktop.org/attachment.cgi?id=24795 is like to be underrun related
[23:57] <mdz> I'd rather not change out any components when I have it in a reproducible state
[23:57] <jbarnes> so if you get a report that sounds like that, the debug patch will confirm it
[23:57] <bryce> jbarnes: ok I see.
[23:58] <bryce> mdz, alright
[23:58] <bryce> I'm going to slap these tools on my laptop and have a go at it


[15:52] <m0norail> Hi. What would be the simplest solution to receive a Telegram alert when my server's disk is almost full or a process is hanging?
[15:58] <ravage> probably a curl command to the telegram api in your monitoring script
[16:02] <m0norail> ravage: Thanks for your reply. I was wondering if there was an existing, lightweight solution, instead of writing my own script. I don't need fancy dashboards, just alerts for a couple of common issues.
[18:29] <PeGaSuS> so, I have a cheap VPS and I'm trying to use netplan. but whenever I try `ENABLE_TEST_COMMANDS=1 netplan migrate` I get `eth0: unknown inet option "up"`
[18:30] <PeGaSuS> this is Ubuntu 20.04
[18:36] <tomreyn> you should probably share your configuration
[18:42] <PeGaSuS> there's no netplan configuration, because that's what `ENABLE_TEST_COMMANDS=1 netplan migrate` iss supposed to do.. my `/etc/network/interfaces` has the following: https://0bin.xyz/?71aab6bfbcea7df6#8FJRZ5MEQDxRgAjQksgDrZWg1znuat9CbmXELW1ZWnQx
[18:47] <PeGaSuS> I wonder if this is a good configuration for netplan (based on what I can understand from it): https://0bin.xyz/?7e6d8d4a015561e3#8zP2vfvoCpRKE2VkJ4pAAB6xCAGx8vmXgwizHwcQsM77
[19:21] <tomreyn> i think those "up" lines are a debian extension, i guess those are not supported by netplan