[01:02] <yowl> I can't log into ubuntu, it gives me a error about power management configurations being incorrect. I had another weird error before this. Can someone please help
[01:04] <yowl> anyone here?
[01:04] <Unit193> yowl: Might want to /join #ubuntu
[01:04] <Unit193> !support
[01:05] <yowl> I am trying there, doesnt seem like anyone can help there
[01:10] <Unit193> Just give it a bit, and please don't crosspost.
[10:39] <blackshirt> hello, some one help me


[15:40] -BottyMcBotFace:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-whiskermenu-plugin 2.3.5 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-whiskermenu-plugin-2-3-5-released-tp57131.html (by Graeme Gott)
[22:49] <JackFrost> bluesabre: I handled 932867 for you. :D


[18:35] <WMRamadan> Hello
[18:36] <WMRamadan> I’m interested in contributing to Packaging and Testing.
[18:36] <WMRamadan> Do I just join the mailing list for this or is there another process involved?
[19:10] <OvenWerks> WMRamadan: That is a great start. We have also been having meetings on Saturdays. I don't remember the UTC time, but it works out to 1200PDT
[19:11] <WMRamadan> OvenWerks: So the meetings are on Saturday 1200PDT here?
[19:12] <OvenWerks> yes
[19:15] <WMRamadan> Great so tomorrow at 1200PDT is the meeting!
[19:16] <OvenWerks> Yes, I haven't heard any notice to cancel
[19:16] <tsimonq2> WMRamadan: Do you have any packaging experience?
[19:16] <OvenWerks> ErichEickmeyer: ^ ?
[19:16] <WMRamadan> Where would you get this notice or info for the meetings?
[19:16] <OvenWerks> mailing list
[19:17] <WMRamadan> I have joined the mailing list on Ubuntu Studio contributors
[19:18] <WMRamadan> I have experience with System Administration, DevOps work abd Programming in PHP/Python/Javascript
[19:18] <WMRamadan> Linux Operating Systems is a primary focus for me
[19:20] <WMRamadan> tsimonq2: What would you recommend I look at first?
[19:21] <tsimonq2> WMRamadan: Try looking through the Debian Policy Manual
[19:26] <WMRamadan> tsimonq2: Thanks will definitely check it out.
[19:27] <tsimonq2> WMRamadan: No problem, let me know.
[19:30]  * OvenWerks has stayed away from packaging because it seems more political than anything else.
[19:36] <tsimonq2> Not really.
[22:03] <OvenWerks> I guess it depends on the package :)  try Carla.


[00:01] <asdfood> where can I see app showdown submissions?
[00:01] <asdfood> or get them
[00:42] <mhall119> asdfood: they've all been submitted to the store, I don't know if they've all been published though
[04:05] <Snake2k> Anyone know how I can contribute to the ubuntu touch messaging app?
[04:05] <Snake2k> that thing needs some massive work lol
[09:49] <Aki-Thinkpad> #ubuntu+1 is invite only; Shucks :P
[09:50] <Aki-Thinkpad> Just to confirm; qml atm doesnt have any easy way to execute system commands at the moment, right?
[09:50] <Aki-Thinkpad> Do i have to write a c++ function, or (can't remember) is there a Qt library I can import?
[10:12] <danielholm> in which package is SystemSettings 1.0?
[11:43] <ogra_> hmm, does anyone know how to tell my app buttons to not emit a haptic effect ?
[13:04] <Aki-Thinkpad> why can't I add a c++ class to my qml project?
[13:27] <DanChapman> Aki-Thinkpad: How are you trying to do it?
[13:28] <Aki-Thinkpad> DanChapman, new file or project> files and classes > c++ class; Inherits QObject
[13:28] <Aki-Thinkpad> DanChapman, It just says it can't be added. Anyways I am trying something
[13:29] <Aki-Thinkpad> let me get back to you in 10 minutes, and if I'm not successful... fill in the blank
[13:29] <DanChapman> Aki-Thinkpad: ok then :-)
[13:30] <Aki-Thinkpad> :P
[13:46] <daker> ogra_: i think it should work out of the box, do you use Button elem ?
[13:46] <ogra_> daker, i want it disabled :)
[13:46] <daker> https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/AbstractButton.qml#L85
[13:55] <asdlol_> ubuntu sdk doesn't scale like other UIs
[13:56] <Aki-Thinkpad> gahh.... executing system commands from qml is not easy >:/
[14:30] <qtros> mhall119 ping
[14:40] <qtros> Guys guys guys! It's very important! Seems that I've found bug in JS execution in SDK. Code works in different ways whichever you run it - with debugger or without. Please, run this simple project http://yadi.sk/d/FIKD_SvuMn2Xn  with Ctrl+R and F5 and give both outputs!
[14:41] <qtros> On my machine (SDK based on Qt 5.0.2) I can see different results (works fine with debugger and badly without)
[15:02] <Aki-Thinkpad> qtros, are you looking for verification? Have you filed a bug report?
[15:04] <qtros> Aki-Thinkpad no, only few minutes ago I understood it - in Qt 5.2 some code works fine, but in Qt 5.2.1 the same code fails, but works fine if you run it with debugger
[15:06] <Aki-Thinkpad> qtros, was reading something about a recent bug that projects with a - in it, are just not running
[15:06] <qtros> Aki-Thinkpad with what in it?
[15:06] <Aki-Thinkpad> dash -
[15:06] <qtros> Aki-Thinkpad no no, I am not about projects, I am about JS code execution
[15:07] <qtros> Aki-Thinkpad much much much much more dangerous bug
[15:07] <Aki-Thinkpad> oh o_o
[15:07] <qtros> Aki-Thinkpad yep
[15:07] <qtros> Aki-Thinkpad that's why I say "Important"
[15:08] <Aki-Thinkpad> qtros, you file a bug report though?
[15:08] <qtros> Aki-Thinkpad I'll try to notify somebody, it can be better than report
[15:09] <Aki-Thinkpad> :)
[15:14] <qtros> Aki-Thinkpad reports sometimes are to slow, but this is critical situation
[15:15] <Aki-Thinkpad> qtros, in my experience, it depends on the components. I don't think anyone has even bothered looking at my compiz bugs, but when it comes to ubuntu-sdk items, a fix was created literally that day.
[15:16] <Aki-Thinkpad> qtros, also if you file it, I don't mind testing to verify, and then we can try and mark it as critical
[15:19] <qtros>  Aki-Thinkpad can you provide an url for doing it?
[15:20] <Aki-Thinkpad> qtros, yah sure!
[15:20] <Aki-Thinkpad> qtros, just to be clear; this is a bug with ubuntu sdk?
[15:22] <qtros> Aki-Thinkpad hmm... seems that it's bug in Qt
[15:22] <qtros> Aki-Thinkpad if so I know where I should report it
[15:22] <Aki-Thinkpad> qtros, oh, in that case, that is a bit different
[15:23] <Aki-Thinkpad> qtros, they have their own bug management system; I honestly would go to #qt ; Its a busy channel which would more than likely pick up your request right away
[15:45] <Aki-Thinkpad> okay I am a bit confused here... No where in my code do I have a PopOver{ element, and yet my program starts with a popover ...
[15:45] <Aki-Thinkpad> I used the tabbed ui template, and took some existing code, shoving it into there.
[16:38] <Aki-Thinkpad> This just confuses me... why does a popover exist?
[16:38] <Aki-Thinkpad> I havnt added it yet
[16:38] <Aki-Thinkpad> and I have no clue how to add buttons to it >:/
[16:53] <Aki-Thinkpad> mmmm apparently Mainview { includes it automatically
[16:56] <Aki-Thinkpad> bah; its right there in the docs > Shucks on me :P
[17:03] <zonovroman> Good morning/afternoon/evening(my case)/night all!
[18:10] <Aki-Thinkpad> hmmmmm that is strange
[18:10] <Aki-Thinkpad> so I got my app to the point where I can execute commands
[18:11] <Aki-Thinkpad> and it seems to be working for the most part, except
[18:11] <Aki-Thinkpad> i cant create text files using >
[18:11] <Aki-Thinkpad> any ideas why? Any workarounds?
[18:14] <Aki-Thinkpad> ah wait...
[18:14] <Aki-Thinkpad> wierd
[21:04] <Aki-Thinkpad> YEEEEEEEEEEEEESSSSSSSSSSssss
[21:04] <Aki-Thinkpad> WOWOWRKRKINGG!!!
[21:04] <Aki-Thinkpad> so happy :)
[21:04] <Aki-Thinkpad> :D
[21:30] <Chyzwar> yoyo How to exit from fullscreen mode in ubuntu SDk
[21:30] <Chyzwar> ?
[21:32] <Aki-Thinkpad> Chyzwar, o_O
[21:32] <Aki-Thinkpad> sec
[21:32] <Aki-Thinkpad> let me try
[21:32] <Aki-Thinkpad> press alt to get the hud, and type "full screen"
[21:32] <Aki-Thinkpad> Chyzwar, ^
[21:33] <Aki-Thinkpad> err, assuming you are using unity
[21:34] <Aki-Thinkpad> oh
[21:34] <Aki-Thinkpad> nvm
[21:34] <Aki-Thinkpad> yah how do you exit full screen ?
[21:34] <Aki-Thinkpad> lol
[21:36] <Chyzwar> I tried F11, but no success.
[21:38] <Aki-Thinkpad> Chyzwar, I tried yelling at it, also no success
[21:38] <Aki-Thinkpad> Chyzwar, going to attempt spitting on it.
[21:55] <Chyzwar> like always, I have good intentions, and he stuff happen
[22:18] <qtros> popey ping


[01:34] <Kon-> Hi, I'm on 18.04. kde-config-fcitx is "installed" by default, but the "installed files" are missing
[01:38] <Kon-> I reinstalled it, let me see what happens. brb
[01:42] <Kon-> fcitx configuration UI gives a different error now. Before it couldn't find a missing /usr/share/kservices5/kcm_fcitx.desktop
[01:43] <Kon-> Now it is https://i.imgur.com/u8bHcRU.png
[06:36] <lordievader> Good morning
[07:54] <acheronuk> Kon-: both kde-config-fcitx libfcitx-qt5-1 installed?
[07:54] <acheronuk> works ok here on 18.04
[10:05] <BluesKaj> 'Morniog folks
[10:07] <lordievader> Hey BluesKaj
[10:07] <lordievader> How are you doing?
[10:09] <BluesKaj> 'Morning folks
[11:23] <daum> acheronuk, any chance you are round - heard you may be able to help with a weird issue i'm having where it seems when i login via kde my user gets it's groups stripped down to only the primary group
[12:01] <acheronuk> daum: I can't explain OR reproduce that issue
[12:02] <lordievader> I think it is somewhere with sddm or the init process of KDE. But I have no idea what is going on there.
[13:07] <Kon-> acheronuk: You were correct. libfcitx-qt5-1 is listed as installed by the package manager, but the files are not there. The same problem I had with kde-config-fcitx earlier.
[13:08] <Kon-> I'm confused as to why these packages are considered installed by default on 18.04 but are not actually present
[13:08] <Kon-> Can anyone else replicate this?
[13:09] <lordievader> Kon-: Does dpkg list it as 'rc'?
[13:12] <Kon-> lordievader: No, ii
[13:13] <lordievader> That means dpkg also thinks it is installed. Guess some script removed the files, or something.
[13:17] <Kon-> That's nice. I wonder what else from my system is mysteriously missing. So far fcitx is the only thing mysteriously broken
[13:17] <Kon-> I reinstalled libfcitx-qt5-1 and was actually able to get into the GUI for fcitx now. But it can't connect to Dbus
[13:17] <Kon-> Going to relog and see if it works
[13:19] <Kon-> Nope, still can't connect fcitx to Dbus
[13:19] <Kon-> If this is following the pattern, I'm assuming another package is missing
[13:21] <Kon-> "Cannot connect to fcitx by Dbus, is fcitx running?" is the exact error
[13:21] <Kon-> Anyone know what might be missing there?
[13:21] <lordievader> Is fcitx running? (`ps aux|grep fcitx`)
[13:22] <Kon-> Looks like the only results are kcm_fcitx and the grep highlight function. So no, it's not
[13:23] <Kon-> In which case I probably want to check the base fcitx package
[13:23] <lordievader> Kon-: What happens when you issue `fcitx` in a Konsole?
[13:25] <Kon-> lordievader: https://paste.ubuntu.com/p/zyWcHhhKxZ/
[13:26] <Kon-> Sure enough, it looks like fcitx-module-dbus is "Installed" but missing
[13:27] <lordievader> Is 'fcitx-frontend-qt5' installed? Or some other frontend?
[13:28] <Kon-> Package manager lists the following frontends installed: fbterm, gtk2, gtk3, qt4, qt5
[13:29] <Kon-> But knowing how things are going, I'd have to double check the files
[13:29] <Kon-> Indeed, /usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so is missing
[13:30] <Kon-> So is the qt4 frontend. Probably the others
[13:31] <lordievader> Reinstall the qt5 one and try running `fcitx` again.
[13:32] <Kon-> Same exact output
[13:32] <acheronuk> Kon-: no, I can't replicate that
[13:33] <Mylon> So my laptop isn't sleeping as it should.  The screen turns off, so I know inactivity time is being tracked properly.  But after 240 minutes, it doesn't sleep.
[13:34] <Kon-> reinstalling fcitx-module-dbus seems to have done the trick. I can access fcitx via GUI
[13:34] <Mylon> I tried using "energy saving" that was already on here, but that didn't work.  I tried downloading a daemon that's supposed to do the trick and editing it's conf.
[13:34] <Kon-> via terminal, however, it still tells me "no useable user interface," but I'm guessing that's a different package
[13:35] <Mylon> I don't remember the name of the daemon...
[13:37] <Kon-> Since I got this system, the only fcitx-related change I have made is to install fcitx-hangul and its dependencies. Is it at all possible that the installation process for that somehow mistakenly removed the KCM and qt5 frontends for fcitx?
[13:42] <acheronuk> Kon-: no. that package doesn't have any pre/post install scripts
[13:44] <Kon-> After I actually fcitx (what I wanted to do yesterday), I'll boot up the live media and see if it was on there. Very strange
[13:44] <Kon-> forgot to type all the words. set up fcitx*
[13:49] <Kon-> Not out of the woods yet, other things are still broken inside the GUI. So the terminal was correct
[14:06] <Kon-> x11 module was missing as well. That would do it
[14:07] <Kon-> So fcitx, fcitx-bin, and fcitx-data were properly installed, but every module, frontend, etc was missing
[14:08] <Kon-> Thanks for the help. I'm curious to take a look at the 18.04 manifest and the installation media and see if those modules were really supposed to be there or not
[16:43] <henk717> Hello Everyone, what is a good method of troubleshooting the technical cause of a kwin_x11 crash? Does it dump a log somewhere?
[16:46] <BluesKaj> henk717, check /var/log/syslog
[16:47] <henk717> Is that the same one KSystemLog opens? Because i could not find anything with the word kwin or kwin_x11 in there when it happened
[16:49] <henk717> Unfortunately its not something i can consistently reproduce, but while chatting i managed to trigger the crash at the 18:45 timestamp
[16:49] <BluesKaj> henk717, no i don't see KSystemLogib /var/log
[16:49] <henk717> KSystemLog is a log reading tool in Kubuntu
[16:49] <BluesKaj> in /var/log
[16:49] <henk717> I just checked the log and do not see anything in there
[16:50] <henk717> https://paste.ee/p/b9SzI
[16:51] <henk717> The crash happens when starting a steam game that disables compositing, Terraria in this case caused the crash but this log does not contain kwin_x11 related information
[20:41] <mirshafie> is it possible to use the Hyper key for shortcuts? it registers as Meta in kde?


[19:16] <mup> Issue operator#463 closed: Document valid schema for pod's set_spec function and how to set environment variables <Created by alexellis> <Closed by alexellis> <https://github.com/canonical/operator/issues/463>


[15:41] <TNKLTSP> guys, I have heard that there is a way to make the sounds work in flash + ltsp envinroment
[15:42] <TNKLTSP> anyone bothered to let me know it
[15:42] <TNKLTSP> google gives me couple of answears but the workarounds leads to broken link


[01:24] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Simplifying software-defined vehicles (SDVs) with EB corbos Linux – built on Ubuntu @ https://ubuntu.com//blog/simplifying-software-defined-vehicles-sdvs-with-eb-corbos-linux-built-on-ubuntu
[01:24] -ubottu:#ubuntu-news- ::planet:: Kubuntu General News: Kubuntu Community Update – March 2024 @ https://kubuntu.org/news/kubuntu-community-update-march-2024/
[01:54] -ubottu:#ubuntu-news- ::planet:: Colin Watson: Task management @ https://www.chiark.greenend.org.uk/~cjwatson/blog/task-management.html
[02:42] <Bashing-om> Opening 830 for several Friday updates.
[02:49] <guiverc> many articles need summary?  (I have some time)
[03:30] <Bashing-om> guiverc: out = three summaries in the Hub and one for LoCo events that is in espanole ya might want to leave to me.
[03:31] <guiverc> first already one (not pasted yet).. yeah I'll leave non-english; struggle enough with just english
[03:31] <guiverc> s/already one/already done/
[03:33] <Bashing-om> Just all you Speedy-Con-guizales :D
[03:33] <guiverc> :)
[03:41]  * guiverc going to paste summaries in a few mins
[03:47]  * guiverc out
[10:37] -ubottu:#ubuntu-news- ::portugal:: E289 Uma Profusão De Abas Em Fogo @ https://podcastubuntuportugal.org/e289/
[22:43] <Bashing-om> UWN: Will open 830 shortly for the Saturday thing - will be a spell wraping up these.
[23:10]  * guiverc won't be around much today.. (maybe gone completely within the hour & may not return)


[08:43] <Hobbsee> @schedule sydney
[08:43] <ubotu> Schedule for Australia/Sydney: 29 Jun 21:00: MOTU Team | 04 Jul 05:00: Technical Board | 05 Jul 06:00: Edubuntu | 06 Jul 06:00: Ubuntu Development Team | 11 Jul 01:00: Kernel Team | 11 Jul 22:00: Edubuntu
[11:05] <cynics> @schedule shanghai
[11:05] <ubotu> Schedule for Asia/Shanghai: 29 Jun 19:00: MOTU Team | 04 Jul 03:00: Technical Board | 05 Jul 04:00: Edubuntu | 06 Jul 04:00: Ubuntu Development Team | 10 Jul 23:00: Kernel Team | 11 Jul 20:00: Edubuntu
[12:48] <bashelier> @schedule Paris
[12:48] <ubotu> Schedule for Europe/Paris: 29 Jun 13:00: MOTU Team | 03 Jul 21:00: Technical Board | 04 Jul 22:00: Edubuntu | 05 Jul 22:00: Ubuntu Development Team | 10 Jul 17:00: Kernel Team | 11 Jul 14:00: Edubuntu
[12:57] <bashelier> hey Lutin
[12:57] <Zic> @now
[12:57] <ubotu> Current time in Etc/UTC: June 29 2007, 10:57:27 - Current meeting: MOTU Team
[12:57] <Lutin> heya bashelier
[12:57] <Zic> o/ Lutin :)
[12:57] <Lutin> hi Zic
[12:59] <dholbach> hiya
[12:59] <geser> Hi
[12:59] <ajmitch> hello
[12:59] <dholbach> who else from the MOTU crew do we have here?
[12:59] <Adri2000> hi
[01:00] <ScottK> ScottK here
[01:00] <StevenK> Hrm. Wonder if ScottK is here this time.
[01:00] <dholbach> to get some rotation going on, who would like to run today's meeting?
[01:00] <dholbach> agenda is here: https://wiki.ubuntu.com/MOTU/Meetings
[01:00] <lionel> hi
[01:00] <dholbach> to get some rotation going on, who would like to write up the minutes of today's meeting?
[01:01] <ScottK> StevenK: Yes.  You can quit wondering.
[01:01] <StevenK> ScottK: :-P
[01:01] <TheMuso> SO I can't be sure of getting them out before I go
[01:02] <dholbach> ok, I'll run the meeting - if somebody could just take a very few notes, that'd be nice
[01:02] <dholbach> persia's item is the first on the agenda: Should setting a date for REVU days be a Fixed topic?
[01:02] <dholbach> I personally think that's a great idea
[01:02] <persia> In the last couple MOTU meetings, there have been discussions of REVU days.  Should this be a standard part of the Fixed Topics?  That wold save anyone remembering each time.
[01:03] <dholbach> excellent idea
[01:03] <dholbach> rock on - thanks persia - somebody please add it
[01:03] <StevenK> Maybe not setting a date, but at least discussing it.
[01:03] <TheMuso> +1
[01:03] <persia> StevenK: I'd rather set a date each time.
[01:03] <persia> (or attempt to do so)
[01:03] <dholbach> yes, I think it's good to settle on it and get moving quickly
[01:03] <ScottK> StevenK: Maybe we set a date like two months from today....
[01:04] <StevenK> Fair enough.
[01:04] <Hobbsee> persia: good idea
[01:04] <dholbach> ok cool, moving on
[01:04] <dholbach> persia's second item is: Does the Sponsorship Process need adjustment for SRUs?
[01:04] <dholbach> hi crimsun
[01:04] <dholbach> persia: what is the problem that you're seeing with sponsoring and SRUs?
[01:04] <persia> The sponsorship queue seems to be working very well for bugs against gutsy, but SRUs are not being processed as quickly.  Should there be a different procedure for these?
[01:05] <persia> dholbach: Right.  The SRUs aren't attracting as much sponsorship attention, and I'm wondering if a process change or a team would help.
[01:06] <ScottK> persia: My generic problem with the UUS queue is I have a hard time telling if something's ready to be sponsored if I only have time to deal with one or two.
[01:06] <ScottK> So I look and throw up my hands.
[01:06] <ScottK> And move on.
[01:06] <ScottK> This is true for SRU or not.
[01:06] <dholbach> so if I want to do a SRU, I file a bug, subscribe ubuntu-universe-sponsors to it and nobody will upload because it's feisty-proposed instead of gutsy in the upload target?
[01:06] <StevenK> I think the problem is that sponsors might go, "Ooh, an SRU. I'm not qualified/care enough to deal with it, since SRUs are Big and Scary"
[01:06] <persia> ScottK: My method is to grab the first couple and take a quick look.  If something is funny, I invalidate and otherwise upload.
[01:06] <ScottK> I did an SRU this week because it was one I hit that was ready.
[01:07] <TheMuso> c
[01:07] <TheMuso> ugh
[01:07] <persia> dholbach: Some of them are being processed, but it doesn't happen as quickly.
[01:08] <crimsun> what seems to be the mean lag order on SRU processing?  Weeks?  Months?
[01:08] <Hobbsee> and you usually get shot down if the fix doesnt actually fix the problem, etc.
[01:08] <dholbach> what could we do to request more reassurement?
[01:08] <persia> crimsun: I haven't calculated that, but there are at least a couple that are from May.
[01:08] <StevenK> Maybe an SRU should adopt a REVU like solution. Two ACKs for it to be okay, and the second one uploads it.
[01:09] <dholbach> StevenK: that'd revert some parts of the universe sru process - we'd have a team that'd evaluate it again - I personally don't think that's wrong at all
[01:09] <ScottK> Maybe people needing sponsoring for an SRU should add a tag for SRU and release (like sru edgy)
[01:09] <StevenK> dholbach: I don't see that as being a bad thing, speaking as a former member of motu-sru. :-)
[01:09] <persia> I think it would be better to have the ACK be optional, rather than required, just to not interfere with the security processing.
[01:10] <ScottK> Once someone's reviewed it they add a tag like motu.
[01:10] <StevenK> SRU isn't security. And shouldn't be.
[01:10] <ScottK> StevenK: +1
[01:10] <dholbach> I think it'd help if people just verified it and asked in #ubuntu-motu or in the mailing list for a second opinion
[01:10] <StevenK> Which is informally my suggestion anyway
[01:11] <dholbach> ok, so how would we go about codifying it?
[01:11] <crimsun> maybe it's a simple lack of publicity
[01:11] <persia> The value to formalisation is that the docs will point people to the right thing (if someone writes a doc), whereas informal may not become part of out collective knowledge.
[01:11] <StevenK> ScottK: We played that game, and then stopped
[01:11] <dholbach> maybe just add a tag needs-sru-verification or something?
[01:12] <persia> StevenK: Is there a reason there couldn't be a volunteer team that worked on them, despite the lack of a formal requirement for ACK?
[01:12] <crimsun> I'm not convinced that throwing more overhead into it really helps; people seemed unhappy with collecting ACKs
[01:12] <StevenK> crimsun: Agreed
[01:12] <TheMuso> crimsun: +1
[01:12] <dholbach> it wouldn't be a necessity
[01:12] <dholbach> just asking for another opinion
[01:12] <dholbach> (in case you're unsure)
[01:13] <dholbach> that tag would say "I'm happy with it, but please make sure and upload if you think it's ok too"
[01:14] <persia> Alternately, with -proposed in place, should there be a strong gatekeeper?  Is there any reason not to upload if it looks sane, and let the standard SRU process filter?
[01:14] <StevenK> Whereas you don't have to set it and can just upload it if you think it's okay as well
[01:14] <crimsun> does LP have an interface for say, a weekly cron executed from tiber (or elsewhere) that would search for tagged SRU bug reports and send an email to ubuntu-motu@ ?
[01:14] <ScottK> One process clarification....  If I sponsor someone's SRU, am I responsible for writing the mail to the mailing list/setting tags/etc or are they?
[01:14] <persia> ScottK: currently, you are (I prefer the sponsoree to be responsible).
[01:15] <ScottK> persia: That's what I thought.
[01:15] <ScottK> That might also be a barrier to getting SRUs uploaded.
[01:15] <dholbach> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=motu-sru-verification
[01:15] <dholbach> or something
[01:15] <ScottK> Maybe we should change that.  After all the one that wrote the fix is most familiar/cares.
[01:16] <TheMuso> After reading the procedure, SRUs are now clearer to me, and are easier than I thought.
[01:16] <dholbach> I think it'd be ok for the sponsor to tell the fix author to write the mail or for them to agree on a procedure
[01:16] <dholbach> so they can figure it out on their own
[01:17] <persia> Is there a mechanism (other than IRC) for removing the uploads from -proposed if the author doesn't follow-up?
[01:17] <ScottK> persia: Unless they are known to be broken, I don't see a harm in leaving them there.
[01:17] <crimsun> persia: the normal "file a bug, subscribe ubuntu-archive"
[01:17] <dholbach> bug reports with ubuntu-archive subscribed?
[01:20] <dholbach> does anybody object adding a tag to ask for a second opinion and making the sponsor-mails-the-lists rule more lax and wiki-ing and announcing it?
[01:20] <persia> So, unless there is more discussion, I'll update the sponsor queue processing guide to indicate that SRUs should be uploaded to -proposed if sane, that MOTUs are welcome to use the motu-sru-verification tag if they aren't sure, and that the author may be responsible for the notifications and follow-up if so agreed in advance.
[01:20] <siretart> hi! (sorry for being late)
[01:20] <StevenK> persia: +1
[01:20] <dholbach> persia: great
[01:20] <ScottK> persia: +1
[01:20] <dholbach> thanks a lot persia
[01:20] <TheMuso> +1
[01:20] <geser> +1
[01:20] <ScottK> siretart: Thanks for volunteering to be in charge of the revised SRU process.
[01:21] <dholbach> ScottK: wants to talk about clamav
[01:21] <ScottK> ;-)
[01:21] <ScottK> dholbach: Let Adri2000 go first.
[01:21] <StevenK> Purge clamav from the archive.
[01:21] <siretart> ScottK: huh? sorry?
[01:21] <dholbach> ok, I'm happy with that
[01:21] <StevenK> Let's move on.
[01:21] <ScottK> siretart: Just kidding.
[01:21] <dholbach> Lutin, Adri2000: your stage
[01:21] <dholbach> https://wiki.ubuntu.com/DaDandMoM
[01:21] <Adri2000> okay
[01:21] <bashelier> may I go ?
[01:22] <Adri2000> I think bashelier has a quick intro
[01:22] <Adri2000> ho
[01:22] <Adri2000> go
[01:22] <bashelier> Ubuntu is a free and open-source distribution, then it seems normal to develop an open-source tool to replace a proprietary one. This is the case for MoM and DaD, and moreover when both tool, one free and one non-free, we usually use the free one. But the fact to have two merge tools is quite confusing, especially that MoM is supported by Canonical and DaD is not.
[01:22] <bashelier> But the fact is that DaD seems to be, at least for universe, very used, see comments in http://dad.dunnewind.net/universe.php for example. Then there are several possible issue to this problem, see the wiki page https://wiki.ubuntu.com/DaDandMoM for further informations.
[01:23] <Adri2000> after a discussion in -motu, we set up this wikipage in order to solve this issue
[01:23] <Hobbsee> what are we attempting to acheieve out of this?  a recommendation on which to use?  a way to find out if and how DaD/MoM can integrate?
[01:23] <Hobbsee> i'm finding this slightly unclear
[01:24] <StevenK> "MoM isn't free, ours is and apparently better, so let's use it for everything." is what I can see.
[01:24] <Adri2000> Hobbsee: avoid confusion, especially for newcomers, about which one to use, why there are two merge systems
[01:24] <persia> StevenK: See Proposal #3
[01:25] <bashelier> 3. Add DaD's features to MoM, and keep MoM closed
[01:25] <dholbach> I think it's better to send the proposal to ubuntu-devel@ and CC keybuk
[01:25] <dholbach> as the scope of the proposal is not just universe
[01:25] <dholbach> and motu
[01:25] <siretart> my 2 : the killer feature of DaD are the comments. they might not be as necessary for main, but I think they help a lot in universe.
[01:25] <TheMuso> agreed. Core devs have to feel comfortable with this as well.
[01:25] <Hobbsee> dholbach: i can do that.  i was speaking to sabdfl about this earlier anyway, and he asked to be CC'd
[01:26] <dholbach> nice
[01:26] <Hobbsee> whihc things of DaD do we want added to MoM?
[01:26] <ScottK> But someone should e-mail keybuck first so he doesn't get blindsided.
[01:26] <Adri2000> dholbach: but I haven't seen any core-dev using DaD, so I'm not sure they are very well aware of the problem
[01:26] <bashelier> Hobbsee: comments
[01:26] <siretart> since it is used a lot in universe, I think we can settle on DaD for universe
[01:26] <Hobbsee> sorry, i meant apart from the comments
[01:26] <dholbach> Adri2000: we all agree that there should be one solution and comments are good
[01:26] <Hobbsee> is there anything *apart* from them?
[01:26] <persia> I thought MoM ran every 15 minutes now.
[01:27] <Adri2000> Hobbsee: open-source, automatic maintainer update
[01:27] <Hobbsee> Adri2000: auto maintainer update?
[01:27] <TheMuso> I'm not so sure that auto maintainer update is the best thing in the world
[01:27] <Hobbsee> oh, maintainer mangling
[01:27] <persia> I don't like the implementation of the auto-maintainer-update - it sometimes breaks things.
[01:27] <siretart> Hobbsee: having active and responsive maintainers
[01:27] <Hobbsee> hi Keybuk
[01:27] <Adri2000> Hobbsee: yes, DaD automagically updates the maintainer field if it isn't yet an @ubuntu.com address
[01:27] <dholbach> Keybuk: https://wiki.ubuntu.com/DaDandMoM is the proposal we're talking about
[01:28] <Adri2000> using the update-maintainer script from Lutin
[01:28] <Lutin> persia: please mails me about that with examples, will have a look asap
[01:28] <Adri2000> hi Keybuk
[01:28] <Hobbsee> Keybuk: the upshot of this is, MoM is missing the comments field and maintainer mangling.  The attempt is to find which one to use and recommend to prospective developers, looking into doing merging.
[01:28] <Lutin> heya Keybuk
[01:28] <persia> Lutin - it's the same class of bugs we discussed before for which I said I'd hunt a patch.  No worries.
[01:29] <Hobbsee> Keybuk: do you have any thoughts on this?
[01:29] <Keybuk> MoM also fulfils our obligations to Debian about returning patches, which DaD doesn't
[01:29] <Lutin> persia: ok, cool
[01:30] <sistpoty|work> Keybuk: but that's unrelated with displaying stuff for merges, right?
[01:30] <Keybuk> no
[01:31] <siretart> Keybuk: espc. in universe land the commenting feature of DaD have been very helpful. Is there any possibility to 'free mom' (or at least the relevant parts) so that we can send you patches which implement them?
[01:31] <Keybuk> it's part of the same process and tool
[01:31] <Keybuk> siretart: that is a question for sabdfl
[01:31] <sistpoty|work> Keybuk: the same tool, I can see, but in what way the same process?
[01:31] <Adri2000> Keybuk: I didn't know returning patches was MoM's job, but could have I known since MoM is closed? :)
[01:32] <Keybuk> Adri2000: that is not a useful comment
[01:32] <Adri2000> that was just to introduce proposal #1
[01:33] <Keybuk> from what I can see
[01:33] <Keybuk> DaD has many of the problems we fixed with MoM a long time ago
[01:33] <Keybuk> (reliance on snapshot.dn, for example)
[01:33] <Keybuk> but has a prettier web interface
[01:33] <Keybuk> MoM is pretty reliable and rock-solid, but has a web interface written by someone who hates HTML (me)
[01:34] <ScottK> So isn't there some way we can take the best of both and (ironically) merge them?
[01:34] <Adri2000> Keybuk: how does MoM get the base version when it's not available on snapshot.d.n?
[01:34] <persia> Keybuk: Could others help with the interface?
[01:34] <bashelier> that's proposal #4
[01:34] <bashelier> Free only part(s) of MoM, such as the UI
[01:34] <Keybuk> the UI isn't non-free
[01:34] <Keybuk> it's exactly what you see there, an HTML page that's written out by some crappy python
[01:35] <Keybuk> MoM could write out a list of packages available for merging, and useful information about them, (such as URLs, version numbers, etc.) to a machine-parseable file
[01:35] <Keybuk> that the DaD UI could pick up and use for tracking
[01:36] <dholbach> what do you think about taking this to ubuntu-devel@ and also including sabdfl in the discussions?
[01:36] <persia> Let's call that proposal #5
[01:37] <dholbach> at the moment, I don't see us coming to a conclusion in this meeting
[01:37] <bashelier> Keybuk: DaD UI is generated from something like http://dad.dunnewind.net/tomerge-universe, then it would be simple yes
[01:38] <sistpoty|work> what if MoM will be out again during the next merge cycle?
[01:38] <Keybuk> ScottK: Canonical would like to be able to pay its developers, and would like to be able to offer tools such as MoM as a paid service to other distros
[01:38] <Keybuk> that is the fundamental rationale for why we've never released the code
[01:38] <ScottK> Keybuk: I understand there's a balance here.
[01:39] <Keybuk> sistpoty|work: it won't?
[01:39] <sistpoty|work> good :)
[01:39] <Keybuk> it was down due to hardware issues; which are unrelated to the software
[01:39] <sistpoty|work> but not unrelated to the freeness :P
[01:39] <ScottK> From a user of the service perspective though, the why is irrelevant.
[01:39] <Keybuk> totally unrelated
[01:40] <Keybuk> if the source were open, you'd still need someone with good bandwidth and .5TB of risk
[01:40] <Keybuk> uh, of disk
[01:40] <Keybuk> :p
[01:40] <TheMuso> hahaha
[01:40] <siretart> bashelier: Adri2000: what do you think about MoM giving status about available packages to merge, and make DaD a frontend to that?
[01:40] <ScottK> Yes.  Getting that didn't seem to be a problem.
[01:40] <bashelier> siretart: I also have a proposal #6
[01:41] <bashelier> siretart: why not to keep both DaD and MoM, and join the comments, I mean have unique comments for the two tools, which would help to avoid duplicated work, and let the choice for the favorite tool.
[01:41] <bashelier> but use DaD as an UI, why not.
[01:41] <Adri2000> siretart: I think it's a good idea
[01:41] <dholbach> ok great
[01:41] <dholbach> let's see how that works out
[01:41] <ScottK> It's certainly a start.
[01:41] <Keybuk> I have no problem with somebody implementing a UI for MoM (I can hardly call the current report html a UI :p)
[01:41] <Keybuk> I can ensure that the appropriate data is available
[01:41] <dholbach> nice :-)
[01:41] <Adri2000> Keybuk: and put this UI on merges.ubuntu.com?
[01:42] <AndyP> like launchpad is closed but still accepts bug reports from it's users (good thing), is MoM open to bug reports/feature requests too?
[01:42] <Keybuk> We also have no problem if a community member wishes access to the MoM source under an NDA, and can hack on it themselves
[01:42] <Keybuk> AndyP: of course
[01:42] <Keybuk> Adri2000: depending on what it's written in, sure
[01:42] <TheMuso> I would like to see if any core devs have an opinion, as the new UI could effect them as well.
[01:42] <geser> is MoM all python?
[01:43] <Keybuk> geser: yes;
[01:43] <Lutin> TheMuso: indeed
[01:43] <TheMuso> Or at the least, get some core dev's thoughts.
[01:43] <Keybuk> the usual theory with core-dev is that MoM implements the minimum necessary
[01:43] <TheMuso> Right.
[01:43] <Keybuk> we don't tend to care so much about claims, or treading on people's toes
[01:43] <Keybuk> since we're a smaller team with a much smaller based of packages
[01:44] <dholbach> ok, are there any more open questions about this item?
[01:44] <TheMuso> Nevertheless, if the UI is going to change, wider opinions should be considered.
[01:44] <persia> I'd like to see comments on main, if only to say (as a MOTU) - I'll be a while on this one - someone should grab it if they're interested.
[01:45] <Keybuk> on the options on the wiki:
[01:45] <Keybuk> #1 is probably untenable, unless you can persuade sabdfl of the benefits since it's his call
[01:45] <ScottK> The DaD team working the UI should also consider the new/updated merges split that MoM has (and explain the difference somewhere).
[01:45] <Keybuk> #2 is also untenable, since MoM does more than just "merges"; not to mention is a much more mature solution than DaD
[01:45] <Keybuk> #3 seems reasonable from a UI POV.
[01:45] <Keybuk> ScottK: hah
[01:46] <Keybuk> ScottK: the DaD team could do a *much* better job <g>
[01:46] <Keybuk> the difference between new/updated is "does the top entry in debian/changelog say 'gutsy'?"
[01:46] <ScottK> Right.
[01:46] <Keybuk> it assumes that if the package has ever been uploaded to the current distro, it is "updated"
[01:46] <Keybuk> so often updated things have never been merged
[01:47] <dholbach> thanks a lot Lutin, bashelier and Adri2000 for working on this
[01:48] <dholbach> is it ok to discuss the implications of the UI changes on the mailing list?
[01:48] <TheMuso> +1
[01:48] <bashelier> dholbach: yes
[01:48] <Adri2000> yep
[01:48] <Lutin> yep
[01:48] <persia> Sounds good to me.
[01:48] <dholbach> thanks a lot - please write also to the mailing list once people can test the UI
[01:49] <siretart> well, we need help from the MoM side
[01:49] <Lutin> well, gotta run. see you later
[01:49] <dholbach> bye Lutin - have a nice day
[01:49] <Keybuk> siretart<EMAIL_ADDRESS>:-)
[01:49] <dholbach> shall we move on to ScottK's item?
[01:49] <Keybuk> (well, when I have my mail server running again <g>)
[01:49] <TheMuso> Thanks for your time Keybuk.
[01:49] <dholbach> thanks Keybuk
[01:50] <dholbach> ScottK: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001747.html - your stage
[01:50] <ScottK> When last we met (that I was here) there was a move to go look at the API differences between libclamav1 and libclamav2 and see how big a deal they are.  I asked for volunteers to work on that (I'm hopelessly unqualified) and got zero volunteers.  The next idea I have for clamav and rdepends support is here: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001747.html - I'll give everyone a minute to read ...
[01:50] <ScottK> It's clear we need to do something, particularly for server LTS support.
[01:50] <Hobbsee> thankyou Keybuk
[01:50] <ScottK> Comments?
[01:50] <ajmitch> as it is, clamav won't be getting updated definitions with 0.8x
[01:51] <persia> I don't think a separate project works well, unless there is strong repository support.  Also, it breaks things if volunteers don't step up for all the rdepends.  Lastly, is makes security updates harder.
[01:52] <ScottK> The trick is that by backporting just clamav, we can give the appearance of coverage, without the actuality.  If you doubt me, go try and find a test virus with the version of clamtk released for Feisty.
[01:52] <ajmitch> persia: that's ok, as it stands clamav can't get security fixes anyway :)
[01:52] <ScottK> My thought is to have a team to test and then have a wiki to describe what's been tested/works/is broken so people know what they are getting into.
[01:53] <ajmitch> ScottK: using PPAs?
[01:53] <persia> ScottK: I like the idea of a team, but why not use normal SRUs for it all?  It's a lot of things to push at once, but I'd rather see it in the normal archive.
[01:53] <ScottK> ajmitch: I'm open on the exact mechanism.  I'd envisioned repositories similar to -backports, but that would get the archive admins off the critical path.
[01:54] <dholbach> I just checked - the diff between libclamav from dapper to gutsy is around 62K lines
[01:54] <ScottK> persia: If there were enough resources to SRU everything that needed changing, we wouldn't be here.
[01:54] <ajmitch> dholbach: that's just the library, right?
[01:54] <TheMuso> ouch
[01:54] <persia> ScottK: True.
[01:54] <ScottK> clamav has a painful number of rdepends.
[01:54] <dholbach> yes clamav*/libclamav
[01:54] <ScottK> We won't get all of them.
[01:55] <ajmitch> a lot of applications would need significant changes (new upstream versions) to work with the newer clamav
[01:55] <ScottK> ajmitch: Yes.  Definitely.
[01:55] <ScottK> That's why the current clamav doesn't qualify for regular backports even.
[01:55] <dholbach> up until now, it looks like added API (which is no trouble) and changed return values
[01:56] <dholbach> it's not feasible to make a wiki page with lists of changes
[01:56] <TheMuso> ~/c
[01:56] <TheMuso> ugh
[01:56] <dholbach> I think it'd take trial&error just trying to compile older versions with the newer clamav
[01:56] <ScottK> dholbach: I was thinking more like a list of known to work/known not to work.
[01:57] <dholbach> if we were to patch things
[01:57] <ScottK> I think patching things just isn't going to get there as you couldn't backport the newer clamav until you had patches for ALL the rdepends.
[01:57] <ScottK> Heat death of the Universe would happen first.
[01:57] <dholbach> we had 21 source package or something?
[01:58] <TheMuso> ajmitch: I was thinking about that earlier.
[01:58] <dholbach> ({build-,}depending on it?
[01:58] <geser> yes, something like that
[01:58] <lionel> do we know how they manage it in volatile.debian.net ? Here there are latest version of clamav. It may break things (I did not dig in it)
[01:58] <ajmitch> TheMuso: at least then it'd be Not Our Problem :)
[01:58] <TheMuso> ajmitch: heh
[01:58] <ScottK> lionel: That's just the latest upstream.
[01:58] <ScottK> It'll break things.
[01:59] <Hobbsee_> ajmitch: try not to think about it
[01:59] <lionel> ah, thanks ScottK
[01:59] <dholbach> ScottK: is dapper -> gutsy what we're looking at atm (regarding API breakage)?
[01:59] <ScottK> No, Feisty.
[01:59] <ScottK> Dapper -> Feisty.
[01:59] <dholbach> ok
[01:59] <ScottK> Feisty is good until the next API change...
[01:59] <dholbach> what if we all grabbed a source package or two each and at least tried building it and see how it goes?
[02:00] <ScottK> But as an example of the kinds of problems backporting the newer clamav's would cause, the clamtk in Feisty can't find virus.
[02:00] <TheMuso> Could we try and encourage upstream to make it easier to support older versions with defs etc?
[02:00] <dholbach> I won't pretend I hadn't other things to do, but I see it as the only realistic option atm
[02:00] <siretart> ScottK: did you talk to upstream about the problem? how do they think about it?
[02:00] <dholbach> for some build problems you could even find patches in the upstream cvs
[02:00] <ScottK> siretart: Upgrade to the latest version.
[02:00] <dholbach> most projects will have adapted to the new clam api
[02:02] <ajmitch> trying to get those patches to apply to the older versions could be interesting
[02:02] <ScottK> The basic clamav perspective, as I understand it, is there is no promise of API stability until they get to 1.0 and whatever happens in the mean time is a personal problem.
[02:02] <TheMuso> hmpf
[02:03] <siretart> ScottK: so they are not helpful at all. interesting
[02:03] <dholbach> not pretty, but this might be a start for a clamtk patch: http://clamtk.cvs.sourceforge.net/clamtk/clamtk/clamtk?r1=1.45&r2=1.40&view=patch
[02:04] <dholbach> I still think that backporting clamav + fixing apps is not impossible
[02:04] <ScottK> dholbach: But you need that for all the rdpends published at the same time you publish the new clamav
[02:04] <ScottK> dholbach: It's the synchronization that'll be the problem.
[02:05] <dholbach> you can add Breaks: for that
[02:05] <dholbach> so people won't upgrade until the new version is in
[02:05] <dholbach> it's ugly, but possible
[02:05] <ScottK> Oh?
[02:05] <dholbach> assuming we had 'breaks:' in dapper already
[02:06] <ajmitch> I don't think we did
[02:06] <dholbach> adding conflicts for things like that is rather discouraged
[02:06] <persia> Real Breaks: support is new for Gutsy, isn't it?
[02:06] <ScottK> If you can do that, then it'd be doable.
[02:06] <ajmitch> "The dpkg in edgy now supports a new kind of dependency relationship, `Breaks'"
[02:06] <ajmitch> so, edgy
[02:06] <dholbach> edgy, ok - hrm
[02:06] <ScottK> So need to backport that first.
[02:06] <dholbach> not going to happen
[02:07] <dholbach> we won't upload a dpkg/apt with new features
[02:07] <ScottK> Then that leaves the LTS release stil screwed.
[02:07] <dholbach> we should discuss that point on the list
[02:07] <dholbach> primarily we should try fixing the stuff
[02:08] <dholbach> even if the deployment of the fix is still an open issue
[02:08] <ScottK> dholbach: But without Breaks, we'd still need fixes for everything before we backport.  That's never gonna happen.
[02:08] <dholbach> ScottK: can you make a wiki page of the affected packages and ask for help in backporting them to work with the new clamav?
[02:08] <dholbach> I'd sign up for one or two
[02:09] <ScottK> First I guess we need to do testing.
[02:09] <dholbach> I think we should offer a complete transition and attack the backport problem as a team
[02:09] <ScottK> OK.
[02:09] <dholbach> some might be easy, for some we might find upstream patches, some might be real work
[02:09] <dholbach> but we'll never find out otherwise
[02:09] <dholbach> great
[02:10] <dholbach> trying to build them in a chroot is of real help already
[02:10] <ScottK> One related point is that the unmodified source package for clamav won't build on Dapper.
[02:10] <ScottK> It needs the Edgy dpgk.
[02:10] <sistpoty|work> sorry, need to be off again... cya
[02:10] <dholbach> see you sistpoty|work
[02:10] <dholbach> ScottK: we should work around that
[02:11] <ScottK> It's a two line change in debian/control.
[02:11] <dholbach> that's fine
[02:11] <ScottK> OK.
[02:11] <dholbach> ok, shall we move on?
[02:11] <ScottK> dholbach: So the action out of the meeting is for me to make a wiki page.
[02:12] <dholbach> yes and announce it on the mailing list
[02:12] <TheMuso> ~
[02:12] <TheMuso> ~
[02:12] <TheMuso> ugh
[02:12] <dholbach> ScottK: thanks a lot for insisting on making a solution happen
[02:12] <ScottK> dholbach: One sec
[02:12] <ScottK> I also think we should make a team of interested people.
[02:12] <dholbach> ok cool
[02:12] <ScottK> OK, now move on...
[02:12] <dholbach> thanks again ScottK
[02:13] <dholbach> we have a few dates to agree on
[02:13] <dholbach> next MOTU meeting?
[02:13] <dholbach> 2 weeks from now? same time?
[02:13] <TheMuso> Sounds good.
[02:13] <dholbach> any objections?
[02:13] <Hobbsee> that works
[02:13] <dholbach> ok cool - who will announce it?
[02:13] <persia> I'd like to see a time rotation, to be fair to those who haven't attended in a month.  +/- 12 hours?
[02:13] <StevenK> No objections, works for me.
[02:13] <Hobbsee> my only objection is that two weeks aftre that, which will be the next proposed meeting, is likely during SLUG
[02:14] <Hobbsee> which various members are planning to actually attend
[02:14] <StevenK> The SLUG meeting is happening now, too
[02:14] <Hobbsee> true
[02:14] <dholbach> ok then thursday - move by 12h?
[02:14] <ScottK> dholbach: Could we have it an hour or two later.
[02:15] <dholbach> sure we can - we just need to agree
[02:15] <ajmitch> dholbach: 12h earlier than now?
[02:15] <ScottK> Make the next one +14 and then go +12 after that
[02:15] <dholbach> ScottK: so time and date would be?
[02:15] <Hobbsee> can you give absolute times please?  not everyone lives on your timezone
[02:15] <dholbach> (it'll be too late for me in europe, but that's fine)
[02:15] <ScottK> OK, then maybe one hour.
[02:16] <ScottK> 1200 UTC Friday, whicher date it is
[02:16] <ScottK> Err
[02:16] <ScottK> 0000 UTC Saturday
[02:16] <ScottK> Then 1200 UTC after that
[02:17] <dholbach> I won't be around - as I'll be in london at that time, but that's fine with me if others can agree on it
[02:17] <ScottK> Anyone?
[02:17] <persia> I like 0 UTC (as part of rotation).
[02:18] <ScottK> 0/12000 UTC.  Any objections?
[02:18] <TheMuso> No.
[02:18] <Hobbsee> should be OK here, 10am
[02:18] <dholbach> so that'd be two meetings?
[02:19] <persia> dholbach: No.  0 UTC is proposed for now + 2 weeks, with 12 UTC sugggested for now L 4 weeks (we'll review in 2 weeks).
[02:19] <dholbach> ok fine with me
[02:19] <dholbach> who announces it?
[02:20] <dholbach> come on
[02:20] <dholbach> persia: thanks
[02:20] <dholbach> next Universe HUG DAY?
[02:20] <dholbach> I'd like us to make an effort to tag bugs and offer mentoring for them
[02:20] <dholbach> I get a lot of requests of people who don't know where to start helping out
[02:21] <dholbach> we should make an effort to help newcomers into the team :)
[02:21] <dholbach> so what about friday next week?
[02:22] <ajmitch> sounds ok
[02:22] <TheMuso> next week?
[02:22] <dholbach> who of you will help out?
[02:22] <ajmitch> nothing better to do on a friday night :)
[02:23] <dholbach> ok, if there's no other proposal, let's go with that, I'll announce it
[02:23] <dholbach> next Q&A sessions?
[02:23] <dholbach> was anybody of you there yesterday?
[02:23] <ajmitch> nope
[02:24] <dholbach> would it be ok to do them in #ubuntu-motu?
[02:24] <Hobbsee> i'd suggest that's a good idea
[02:24] <dholbach> ok
[02:24] <persia> That seems a better place.
[02:24] <AndyP> i think it was forgotten about, and no one turned up in #ubuntu-classroom looking for Q&A... perhaps better advertising next time :)
[02:24] <dholbach> shall we do them in thursday two weeks at 0 and 12 utc?
[02:24] <dholbach> if you have a blog, please blog about all the events we do
[02:25] <dholbach> I'll do that too and announce the Q&A sessions, if we agree on the date and time
[02:25] <dholbach> ok, I take that as no objections
[02:25] <dholbach> moving on
[02:25] <dholbach> next REVU day?
[02:26] <dholbach> as the situation is rather desperate.... what about monday? :-)
[02:26] <TheMuso> I'd rather not have it in the next week, as I'd like to help, but won't be around.
[02:26] <dholbach> TheMuso: we'll do another revu day the week after that - how about that?
[02:26] <dholbach> so best to agree on two dates
[02:26] <TheMuso> dholbach: I'm easy, but would like to help
[02:27] <dholbach> persia: working through the lists of REVU and ubuntu-{main,universe}-sponsors?
[02:27] <persia> So two days?  I like Tuesdays or Thursdays.
[02:27] <dholbach> TheMuso: cool
[02:27] <dholbach> oh, I mean a day each in next week and the one after that
[02:27] <persia> dholbach: Ah.  I wonder if there shouldn't be a wiki page or something.
[02:27] <ScottK> Wed next week is a major holiday in the US.
[02:27] <dholbach> persia: MOTU/Reviewing? :)
[02:28] <dholbach> ScottK: so you think it'd be a good thing to do it on wednesday?
[02:28] <ScottK> dholbach: No.  Stay away from it.
[02:28] <dholbach> ok
[02:28] <dholbach> the next two mondays then?
[02:28] <ScottK> Independence Day generally has a lot of people outside and away from computers here.
[02:29] <persia> dholbach: Cluttered namespace, but I'll add a note on REVU days to https://wiki.ubuntu.com/MOTU/Packages/Reviewing
[02:29] <ScottK> Many people travel too, so Monday is good.
[02:29] <dholbach> persia: thanks
[02:29] <dholbach> ok cool
[02:29] <dholbach> I'll make sure to announce it
[02:29] <dholbach> and please blog about it, if you can - it's good to stir up some interest in the activities we do, they deserve it :)
[02:29] <dholbach> I think that's all from our agenda
[02:30] <TheMuso> :p
[02:30] <dholbach> do we have anything else?
[02:30] <jhansonxi> I have a question about Wine desktop files
[02:30] <dholbach> jhansonxi: would it be ok to ask it in #ubuntu-motu?
[02:30] <dholbach> ScottK: absolutely
[02:30] <ScottK> just a note for the minutes
[02:31] <ScottK> Since I don't think either is present.
[02:31] <ajmitch> are we up to date with new MOTU applications?
[02:31] <dholbach> thanks calc and nixternal for all the work you put into Ubuntu :-)
[02:31] <ScottK> Actually, congrats nixternal
[02:31] <dholbach> ajmitch: no, bluekuja and YokoZar and one core-dev application are in the loop
[02:32] <dholbach> ok, that's that then
[02:32] <dholbach> thanks all for coming - have a nice day
[02:32] <TheMuso> np
[02:33] <dholbach> ajmitch: bluekuja and yokozar don't have any vote
[02:33] <ajmitch> ok
[02:34] <dholbach> welcoming new MOTUs should be
[02:34] <dholbach> I already sent mails to ubuntu-devel@ about it
[02:34] <dholbach> but it'd be nice to welcome them in the meeting also
[02:35] <dholbach> for status of pending applications I'm not sure
[02:35] <dholbach> I mean I'm happy to give a statement on it, but I don't know if it helps much
[02:35] <persia> Right.  I withdraw that - it's properly MOTU Council.
[02:35] <ajmitch> and we don't have separate MC meetings
[02:36] <persia> ajmitch: But you deliberate in other forums, no?
[02:36] <ajmitch> only the mailing list
[02:37] <persia> Hmm.  I stand by my withdrawl, but wouldn't oppose another suggesting it.
[02:37] <ajmitch> ok, meeting over, let's all go home :)
[02:38] <ScottK> Bye all.
[06:03] <asac> @schedule
[06:03] <ubotu> Schedule for Etc/UTC: 03 Jul 19:00: Technical Board | 04 Jul 20:00: Edubuntu | 05 Jul 20:00: Ubuntu Development Team | 10 Jul 15:00: Kernel Team | 11 Jul 12:00: Edubuntu | 12 Jul 15:00: Ubuntu Development Team


[20:26] <arraybolt3_wc> Heads-up, the emergency fix for the Budgie installer seems to have potentially broken things. The installer didn't appear at startup, I had to find it in the application menu where it was called "Install RELEASE". Also the slideshow is just a plain white background when installing in Ukranian (which I just did with the help of Google Translate).
[20:27] <fossfreedom_> Install release is expected
[20:27] <arraybolt3_wc> The install finished successfully though.
[20:27] <arraybolt3_wc> Ah, ok
[20:28] <fossfreedom_> Plain white background is odd. Is it the same with ubuntu itself?
[20:28] <fossfreedom_> ... and nice that u
[20:28] <arraybolt3_wc> Not sure, and also I used Ukranian, not English, so...
[20:28] <arraybolt3_wc> could just be a localization issue.
[20:28] <arraybolt3_wc> (On the bright side none of the text seemed problematic, so the ISO fix itself worked.)
[20:29] <fossfreedom_> Nice that you are looking at Ukrainian
[20:29] <arraybolt3_wc> I'll try an English install and see what happens, and also try a standard Ubuntu installation (though it may take a while for me to download that ISO).
[20:58] <samlane> Can confirm white slideshow with Ukrainian install on Budgie, slideshow works fine with English install, haven’t tried anything else
[21:22] <arraybolt3_wc> I'm not going to have the time to test standard Ubuntu as the download is going very slowly and I have to leave some time before 7 PM Central Time.
[21:22] <arraybolt3_wc> Unless the ISO download speeds way up pretty soon that is.
[21:22] <arraybolt3_wc> oh wow, I closed my laptop lid and suddenly it did speed way up :P
[21:22] <arraybolt3_wc> weird
[21:27]  * Eickmeyer blames arraybolt3_wc 's snail of an internet connection
[21:28] <arraybolt3_wc> Eickmeyer: If you want to buy me faster service I won't complain (j/k)
[21:28] <Eickmeyer>  ERR:NEEDJOB
[21:28] <Eickmeyer> Donations accepted at https://ubuntustudio.org/contribute (j/k but please)
[21:28] <arraybolt3_wc> oof, sorry to hear that
[21:29] <arraybolt3_wc> heh, I would if I could but ERR:NEEDJOB over here too (plus ERR:NEEDPAYPALACCOUNT)
[21:30] <Eickmeyer> No worries. :_
[21:30] <Eickmeyer> s/:_/:)


[10:55] <jmux> Hi. I tried to follow the documentation for submitting a patch for inclusion in Ubuntu Xenial kernel and feel a little bit lost.
[10:55] <jmux> I've submitted lp#1745130 and I've written a mail to<EMAIL_ADDRESS>[11:30] <apw> LP: #1745130
[11:31] <apw> jmux, i have just approved your post to the list ... things patch wise are progressing slower than normal, because of meltdown/spectre causing respins all the time
[11:31] <apw> jmux, but it looks like you have done the right things in general
[11:32] <apw> jmux, if you could include the sha1 of the original fil upstream in the bug that would help application
[11:32] <apw> jmux, doh you did in the bug, so all is well
[11:59] <jmux> apw: Thanks. I'm not in a hurry. I even could patch the kernel. The HW is still in evaluation and I have more patches, which I have to send upstream first.
[11:59] <apw> jmux, ack great
[12:00] <jmux> apw: and I have to test 18.04, which will be our next rollout at the end of this year.
[18:55] <jmux> jsalisbury: Thanks for the kernel for LP: #1745130. Have to leave in a few minutes. Works as expected.
[21:13] <yetoo> How does one manually uninstall a kernel or debug its postinst script
[21:14] <yetoo> because every time I try to uninstall a kernel dpkg spits out an error
[21:15] <yetoo> You can view the error in the most recent attachments here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744214
[21:17] <smeso> yetoo: what's the output of `file /etc/kernel/postinst.d/vboxadd` ?
[21:19] <TJ-> We've seen that issue before with /etc/kernel/postinst.d/vboxadd
[21:20] <TJ-> yetoo: is the root file-system on LVM?
[21:25] <TJ-> oh, no, it's presented as sda1 from disk/by-id/ata-VBOX_HARDDISK_VB5edd919d-c9befa35-part1 which has /dev/disk/by-uuid/d15b971c-a592-4259-b4fd-b74cf3c4d03c
[21:26] <TJ-> I've seen the UUID problem when using LVM and passing ROOT=UUID=xxxx (which is an LV but vgchange -ay isn't fired)
[21:32] <TJ-> yetoo: I'd check if something is being added/removed from the initrd.img that's breaking things; look in /usr/share/initramfs-tools/{hooks,scripts} and /etc/initramfs-tools/{hooks,scripts}


[12:37] <jbailey> mjg59: So it seems the patch killed any system without a swap partition, joy.
[12:37] <jbailey> mjg59: I thnk I have it fixed.
[12:37] <jbailey> =)
[12:37] <mjg59> jbailey: Hrm?
[12:38] <jbailey> The other suspend shell script had a guard to make sure that if the RESUME variable wasn't defined, that it didn't attempt to figure everything out.
[12:38] <jbailey> This one didn't have the guard.
[12:38] <jbailey> It turns out that [ -e ${RESUME} ]  returns true when RESUME isn't defined.
[12:39] <mjg59> Ah
[12:39] <mjg59> Right
[12:39] <jbailey> [ -e "${RESUME}" ] , however, returns false.
[12:39] <mjg59> Hm
[12:39] <mjg59> But it's still failing to resume, for some reason
[01:20] <jbailey> mjg59: Cerainly on my laptop resume doesn't seem to be defined.
[01:20] <jbailey> But hopefully, I can kill all the critical bug reports at least.
[01:20] <jbailey> *sigh*
[01:30] <mjg59> jbailey: "defined"?
[01:37] <jbailey> //sys/power/resume is 0:0
[01:38] <mjg59> Hm. When is this? After boot?
[01:45] <mjg59> jbailey: Ok.  Yes, udevstart is run after load_modules has finished
[01:47] <jbailey> Ahahahaha
[01:47] <jbailey> Hm
[01:47] <jbailey> But why didn't the second call catch it?
[01:47] <mjg59> Dunno
[01:47] <jbailey> It should at least still be set, since the suspend script is still there?
[01:48] <jbailey> I think I want to spend another day thinking about how to lay this all out.
[01:48] <mjg59> I'd prefer that we had something in the archive that worked, to be honest
[01:48] <jbailey> Most people will have swap on lvm, I think.
[01:48] <mjg59> Really?
[01:48] <jbailey> IIRC, the installer does LVM by default now.
[01:48] <mjg59> Uhm.
[01:48] <mjg59> Not in my experience.
[01:48] <mjg59> Unless you tell it to use the whole disk?
[01:49] <jbailey> Dunno.
[01:49] <mjg59> Hm.
[01:49] <jbailey> All of my machines are whole-disk installs.
[01:49] <jbailey> But I thought that it was doing LVM in general now.
[01:49] <mjg59> Right. Hrm.
[01:50] <mjg59> Oh, I'm told that it's easy to check if all the disks in an LVM are present
[01:50] <mjg59> One of the vg commands will tell you
[01:54] <mjg59> jbailey: Ok, yeah. A udevstart sorts it.
[01:54] <jbailey> So in what order should this happen then?  Attempt to walk the PCI bus, find card.  Find ide-disk, sd, and friends.
[01:54] <jbailey> udevstart
[01:54] <mjg59> Yeah.
[01:54] <jbailey> Mm, no, step before.
[01:54] <jbailey> Start md, lvm, evms.
[01:54] <jbailey> I'm wrong, those are after udevstart
[01:54] <mjg59> udevstart needs to be before md and lvm
[01:54] <mjg59> Yeah
[01:54] <mjg59> Except we only want to start them if we have all member disks
[01:54] <jbailey> Right, but that's a good hack to put the in lvm script anyway
[01:55] <mjg59> Sure
[01:55] <mjg59> Hurrah. Working hibernate.
[01:55] <jbailey> Then walk the bus a second time, looking for usb and network drivers.
[01:55] <mjg59> Yeah
[01:55] <jbailey> start md, lvm, and evms. =)
[01:55] <jbailey> Sorry udevstart.
[01:55] <jbailey> Then start those.
[01:56] <jbailey> Then attempt hibernate resume again in case the device was on one of those and it happens to work for people.
[01:56] <mjg59> Yeah
[01:56] <jbailey> Sick.
[01:56] <mjg59> Heh
[01:57] <jbailey> Mind you..
[01:57] <jbailey> I guess I can shortcut that second pass if I have swap and the root device.
[01:58] <jbailey> All I need is USB at that point in case they drop to a shell.
[01:58] <jbailey> I wonder how many people will get screwed if I suddenly don't load their ethernet cards in the initramfs?
[01:59] <zul_> heylo
[01:59] <jbailey> mjg59: Are you getting lots of reports of fails to resume?
[01:59] <jbailey> I have 15775
[01:59] <mjg59> jbailey: Well, it's broken with current initramfs-tools
[01:59] <mjg59> As in, there's no way it can work
[01:59] <jbailey> Right.  I'm wondering if it's urgent enough that I should stay up, or if I can consider my workday over and dive in tomorrow.
[01:59] <jbailey> I'd sortof like dinner and to see my belle.
[02:00] <mjg59> Heh
[02:00] <mjg59> Would it be possible to just add the one-line udevstart to fix some cases?
[02:00] <mjg59> I'll take a look at the lvm stuff and let you know what I find
[02:01] <mjg59> It leaves things no worse than they are right now
[02:01] <jbailey> Oh, I figured out why the suspend script isn't running.
[02:01] <jbailey> It needs a chmod +x
[02:01] <mjg59> Ah. heh.
[02:02] <jbailey> When I recovered it from bzr, it didn't preserve that.
[02:02] <jbailey> I'd really prefer to leave it until I can actually do a test run with it.
[02:02] <mjg59> I've just done a test run with that case
[02:02] <jbailey> I'm basically going to go offline for the night in a few minutes and don't want to look for more "OMG can't boot" bugs. =)
[02:03] <mjg59> The one change I made was to add the udevstart
[02:03] <zul_> heh liar
[02:03] <jbailey> mjg59: You have main upload privs, don't you? =)
[02:03] <mjg59> jbailey: Heh. Indeed.
[02:03] <mjg59> jbailey: Have you uploaded the one with the resume guard quotes?
[02:03] <jbailey> mjg59: Feel free.  That way they beat on your for touched-it-last priviledges.
[02:04] <jbailey> mjg59: I have.  If you're using bzr, I've updated that to 0.27
[02:04] <mjg59> jbailey: Hm. vgscan ought to return an error, I'm told
[02:04] <mjg59> jbailey: Ok, where's your tree?
[02:04] <jbailey> http://people.ubuntu.com/~jbailey/bzrtree/initramfs-tools
[02:04] <mjg59> Thanks
[02:05] <jbailey> vgscan doesn't take a vg as a parameter, though.
[02:05] <jbailey> The root vg is the only thing that needs to promise to be present at boot time.
[02:05] <jbailey> Other arrays and stuff could require fancier setup that requires an otherwise running system.
[02:06] <mjg59> Hmm. Yes.
[02:06] <jbailey> I wonder if vgdisplay has it.
[02:06] <mjg59> There must be a reasonable way to get it out of the metadata.
[02:06] <jbailey> With lvm, it's not obvious what's reasonable or not.
[03:42] <BenC> mjg59?
[03:42] <mjg59> BenC: Hi
[06:30] <desrt> BenC; poke
[06:40] <fabbione> morning guys
[07:43] <fabbione> BenC, jbailey: ping?
[02:43] <zul> morning
[02:48] <fabbione> hey zul
[02:51] <zul> hey fabbione how goes it?
[02:51] <fabbione> zul: working as usual
[02:51] <fabbione> you+
[03:01] <zul> ditto
[03:20] <Diziet> Ah, hello fabbione.  I just wanted to have a quick word with you about that kernel-package dependency thing.
[03:20] <Diziet> Do you have a moment ?
[03:22] <fabbione> Diziet: can you give me 5/10 minutes?
[03:23] <Diziet> Sure.
[03:30] <fabbione> Diziet: ok...
[03:30] <fabbione> i am back
[03:33] <fabbione> Diziet: ??
[03:33] <Diziet> Hello.
[03:34] <fabbione> so remind me where we left the discussion
[03:34] <Diziet> So this is about 15488.  Can you remember what I was saying on Friday ?
[03:34] <fabbione> yes
[03:34] <fabbione> till we agree to stop for the day :)
[03:34] <Diziet> kernel-package has a hardcoded value `gcc', which it inserts into the Depends of the source .deb's that it causes to be created.
[03:35] <Diziet> mdz and the submitter seem to think just changing that to gcc-3.4 would be correct.
[03:35] <fabbione> Diziet: one second that i am digging code and stuff...
[03:35] <Diziet> Since when you use kernel-package with one of our kernels they end up trying to build against gcc-3.4.
[03:36] <fabbione> Recommends: libc-dev, gcc, make
[03:36] <fabbione> ok
[03:36] <fabbione> gcc is only Recommended
[03:36] <fabbione> not a Depends:
[03:36] <fabbione> now we have 2 situations we need to analize
[03:36] <fabbione> and that's why i didn't agree with your changes
[03:37] <fabbione> 1) building our linux-source
[03:37] <Diziet> Yes, I see what you were saying about my change which I agree was wrong.
[03:37] <fabbione> 2) building a generic vanilla kernel
[03:37] <fabbione> ok
[03:37] <fabbione> let's take it again point by point
[03:37] <Diziet> Right.
[03:37] <fabbione> so we are sure we don't overlook anything
[03:38] <fabbione> for the sake of release in 3 weeks :)
[03:38] <fabbione> our kernel must be built with gcc-3.4
[03:38] <fabbione> this is hardcoded
[03:38] <fabbione> so
[03:38] <fabbione> the Package: linux-source-2.6.12 must Depends on gcc-3.4
[03:38] <Diziet> Hardcoded in the Makefile you get when you unpack one of our kernel source trees (no matter how you got it).
[03:38] <fabbione> or Recommends: gcc-3.4
[03:39] <fabbione> and I agree with BenC that should be a Recommentds
[03:39] <Diziet> Right.
[03:39] <fabbione> Diziet: exactly
[03:39] <fabbione> it's hardcoded in the makefile
[03:39] <Diziet> When you say `the Package: linux-source-2.6.12' you mean _our_ `linux-source-2.6.12'.
[03:39] <Diziet> But of course someone could sensibly use make-kpkg to make their own linux-source-2.6.12.
[03:39] <fabbione> Diziet: we have a source called linux-source-2.6.12 that B-D on gcc-3.4
[03:39] <Diziet> That's one of the things it's for.
[03:39] <Diziet> Right.
[03:39] <fabbione> and a package that ships our source + patches that Recommends: gcc
[03:40] <fabbione> the latter is wrong
[03:40] <Diziet> Indeed so.
[03:40] <fabbione> so we all agree that P: l-s-2.6.12 must either Depends: gcc-3.4 or Recommends: gcc-3.4
[03:40] <fabbione> because i might download the source only for reading
[03:40] <Diziet> _Our_ l-s-2.6.12, yes.
[03:40] <fabbione> yes
[03:40] <Diziet> Right.
[03:40] <fabbione> our
[03:40] <fabbione> i didn't talk about pint 2 at all
[03:41] <Diziet> OK.
[03:41] <fabbione> that's why i isolated the cases
[03:41] <fabbione> i am still on point 1)
[03:41] <Diziet> Carry on ...
[03:41] <fabbione> so for 1) that's the only change required
[03:41] <fabbione> now
[03:41] <fabbione> 2) is more complex
[03:41] <fabbione> it is way more complex
[03:41] <fabbione> why:
[03:42] <fabbione> a) we don't know what kernel the user is building
[03:42] <fabbione> b) and we don't know why
[03:42] <fabbione> so we can't force a gcc to him
[03:42] <fabbione> he might be as well compiling a kernel with gcc-4.0 for debuggin
[03:42] <Diziet> Currently, make-kpkg does do that.  That is, if the user uses make-kpkg to make a linux-source.deb, it will say Recommends: gcc.
[03:42] <fabbione> we have no idea
[03:42] <Diziet> Right.
[03:43] <fabbione> so i still believe that Recommends: gcc is the right solution
[03:43] <fabbione> i see no winner in forcing a gcc
[03:43] <Diziet> In this second case ?  Certainly there shouldn't be a Depends.
[03:43] <fabbione> ok..
[03:43] <Diziet> But yes, it seemed to me that either Recommends: gcc or nothing at all would be best.
[03:43] <fabbione> and that's how the situation is
[03:44] <Diziet> Nothing at all is a reasonable option - after all, the user knows what they're doing and we shouldn't trip them up.
[03:44] <fabbione> also.. who compile its own kernel, needs to know what it is doing
[03:44] <Diziet> Exactly.
[03:44] <Diziet> Now, AIUI both of these cases are generated by the same code in make-kpkg.
[03:44] <fabbione> so for me.. personally.. 15488 is NOTABUG :)
[03:45] <Diziet> Um, you're saying that _our_ linux-source packages are _not_ made with make-kpkg ?
[03:45] <fabbione> Diziet: yes it is made with make-kpkg
[03:45] <Diziet> So surely atm the dependencies are wrong ?
[03:45] <fabbione> Diziet: yes.
[03:46] <fabbione> but we need to fix it in debian/control in linux-source-2.6.12
[03:46] <fabbione> and not in kernel-package :)
[03:46] <fabbione> our l-s-2.6.12 debian/rules is insane
[03:46] <Diziet> But linux-source-2.6.12, if it is make with make-kpkg, has an autogenerated debian/control made by make-kpkg.
[03:46] <Diziet> s/is make/is made
[03:47] <fabbione> iirc it is overwritten
[03:47] <fabbione> there are scripts that copies parts of debian/control to differnt packages
[03:47] <Diziet> Scripts where ?
[03:47] <fabbione> inside debian/
[03:47] <Diziet> In linux-source-x.y.z's source package ?
[03:47] <fabbione> it's all contained in one dir (at least!)
[03:47] <fabbione> yes
[03:48] <Diziet> But make-kpkg makes up a source package out of whole cloth.
[03:48] <fabbione> Diziet: be aware that our source doesn't call make-kpkg on itself
[03:49] <fabbione> the source is copied/mangled/trashed/reconfigured several times
[03:49] <fabbione> and that happens in debian/build
[03:49] <fabbione> building our kernel is not only executing make-kpkg
[03:49] <fabbione> there are plenty of more problems we need to address
[03:50] <fabbione> Diziet: you also want to check the scripts that it calls
[03:50] <Diziet> Yes, so I see.
[03:50] <Diziet> kernel-wedge gen-control > debian/control
[03:51] <fabbione> yes.. kernel-wedge is for udebs
[03:51] <fabbione> control file is generated via control.stub
[03:51] <fabbione> nothing too fancy
[03:52] <fabbione> Diziet: line 162
[03:53] <fabbione> sorry 163
[03:53] <fabbione>         cp debian/control $(srcdir)/debian
[03:53] <fabbione> that one copies our control file into debian/build/linux-source-2.6.12/debian/
[03:53] <Diziet> Right.
[03:53] <fabbione> the dir that will generate the source afterwards
[03:53] <Diziet> But even debian/control.stub looks like it should be autogenerated.
[03:54] <Diziet> It's full of version numbers.
[03:54] <fabbione> Diziet: ALT
[03:54] <fabbione> control.stub and control are only for udebs
[03:54] <Diziet> ALT ?
[03:54] <fabbione> ALT = STOP :)
[03:54] <fabbione> sorry...
[03:54] <fabbione> itaglish
[03:54] <fabbione> you will learn that my itaglish > pure english :P
[03:55] <fabbione> don't get confused by control.stub and control
[03:55] <fabbione> that's not relevant for we need here
[03:55] <fabbione> just think at them like debian/control
[03:55] <fabbione> the mangling required for udebs is another story
[03:56] <fabbione> (brb.. mother nature is calling ;))
[03:56] <Diziet> So when you update to a new upstream kernel, how to the version numbers get furtled in these control files ?
[03:56] <Diziet> OK.
[03:56] <fabbione> (= i need to take a piss )
[03:56] <Diziet> Yes, that's not itaglish :-).
[04:01] <fabbione> Diziet: sed -i -e 's/2.6.12/2.6.whatever/g' debian/control.stup
[04:01] <fabbione> and for a little bunch of more files
[04:02] <fabbione> it's suboptimal
[04:02] <fabbione> but I never had the time to rewrite that mess
[04:02] <fabbione> so we can live with it...
[04:02] <fabbione> and we should merge our build system with the Debian one
[04:02] <Diziet> Ah, right.  So the right answer is just to change control and control.stub and leave kernel-package alone.
[04:02] <fabbione> exactly
[04:02] <fabbione> control.stub is enough :)
[04:03] <fabbione> control is regenerated
[04:03] <Diziet> OK :-).
[04:03] <Diziet> Do you want me to attempt to do that ?  Is this stuff in arch or something or just normal uploads ?
[04:03] <fabbione> Diziet: see /topic :)
[04:03] <fabbione> i can do it.. it's one line change
[04:04] <Diziet> Hey, I looked at the topic _yesterday_ :-).
[04:04] <fabbione> yeah...
[04:04] <fabbione> debian/ is in baz
[04:05] <Diziet> Right.  Well, I'll leave you to do it I think; probably quicker than me faffing, unless I'm going to turn into an actual kernel bod.
[04:05] <fabbione> Diziet: that's ok..
[04:06] <fabbione> Diziet: it is important that we coordinate changes to the kernel build system all together
[04:06] <fabbione> there are a lot of bits that need to fall down in the right place
[04:06] <fabbione> otherwise we can wave kthxbye to it
[04:14] <Yagisan> how much space is needed when compiling linux-source ?
[04:14] <Yagisan> I've tried to add a driver to my local copy, but it dies in my pbuilder complaining it is out of space.
[04:18] <fabbione> Yagisan: it depends.. it can be quite a lot
[04:18] <fabbione> up to 550MB for a build
[04:19] <fabbione> sorry per flavour
[04:19] <Yagisan> ah
[04:19] <Yagisan> so my 11GB tmpfs wasn't enough
[04:20] <fabbione> Yagisan: they should be plenty...
[04:20] <fabbione> but well... if it complains about space, you must have done something wrong
[04:22] <Yagisan> well, all I did this morning was "sudo pbuilder build linux-source-2.6.12_2.6.12-8.13.dsc"
[04:22] <fabbione> Yagisan: it depends how you did configure pbuilder
[04:22] <fabbione> by default it uses /var/cache
[04:23] <fabbione> so if your /var/cache/pbuilder/build is a tmpfs, than yes.. you were building in RAM
[04:23] <fabbione> otherwise you were writing on fs
[04:24] <Yagisan> I set BUILDPLACE=/tmp/ in pbuilder and /tmp is tmpfs
[04:25] <Yagisan> so I think pbuilder is set up ok
[04:25] <Yagisan> I've never build anything this big in pbuilder though
[04:25] <fabbione> Yagisan: just be sure it is really using /tmp than
[04:46] <Yagisan> ok. I've just freshly unpacked linux-source-2.6.12_2.6.12-8.13.dsc and confirmed it is building in /tmp, now to wait and see if it crashes again - this time with logging on.
[04:51] <mkrufky> fabbione: about v4l/dvb kernel updates (for breezy):  what kernel should I patch against?
[04:52] <fabbione> mkrufky: if you really want to spend your time on it, against our tree
[04:52] <fabbione> but we are really too close to release to update an entire subsystem
[04:52] <fabbione> i think it's more worth to start working from the dapper kernel
[04:52] <mkrufky> ah, then i wont bother... no big deal...
[04:53] <mkrufky> i guess that kernel will be ready in about a month, right?
[04:54] <fabbione> mkrufky: i think in 10 days we can start working on dapper kernel
[04:54] <fabbione> we won't be able to upload it
[04:54] <fabbione> but given that breezy is uber frozen
[04:54] <fabbione> we can start playing around in a devel branch
[04:55] <mkrufky> hmmm..... so will i get access to this branch?
[04:57] <fabbione> mkrufky: if you use baz yes of course
[04:57] <fabbione> you won't be able to commit directly to it
[04:57] <fabbione> but you can branch off
[04:57] <fabbione> and publish your branch
[04:57] <fabbione> and we can merge back
[04:57] <fabbione> no big deal
[04:58] <fabbione> zul did this for all the hoary release...
[04:58] <fabbione> it did work pretty well
[04:58] <mkrufky> thats fine... i guess i have a new tool to learn then.... (never heard of baz, but there's always a good time to learn)
[04:58] <fabbione> ehhe
[04:58] <fabbione> apt-get install bazaar
[04:58] <fabbione> there are plenty of howto's
[04:58] <mkrufky> got it
[04:58] <fabbione> for basic stuff i can even help you :)
[04:59] <mkrufky> i'm downloading it now... will play around a bit
[04:59] <fabbione> sure
[05:25] <zul> i did what?
[05:25] <zul> oh...heh
[05:26] <zul> heh i wasnt special enough to get direct access ;)
[05:27] <mkrufky> dont be jealous... im not special enough either :-P
[05:27] <BenC> mjg59: ping
[05:28] <mjg59> BenC: Hi
[05:28] <mjg59> Hm. Are we allowed to break the ABI now?
[05:28] <BenC> hey, can I close 14790?
[05:28] <BenC> no :)
[05:28] <mjg59> Shit. Right.
[05:28] <mjg59> BenC: Yeah, looks like that can be closed
[05:30] <mjg59> Argh.
[05:30] <mjg59> I fear it may be impossible
[05:31] <mjg59> Right. It breaks ABI in the pcmcia socket driver
[05:32] <mjg59> If we want to support recent TI PCMCIA chipsets properly, they need an extra prod to power up properly by the looks of it
[05:32] <zul> mjg59: i cleaned up the patch a bit last night so it applies will be doing a test build tonight and will commit it to my archive tonight for BenC
[05:32] <mjg59> Maybe I can just drop that hunk.
[05:32] <mjg59> zul: Which patch?
[05:34] <fabbione> meh breaking the abi is still possible, but mdz is not going to like it
[05:34] <mjg59> I'll see if I can do this without it
[05:36] <fabbione> BenC: i am working on fixing 15488, 14736 and 13506
[05:36] <fabbione> if you already did any of them, please let me know
[05:38] <zul> mjg59: sk98lin
[05:39] <zul> BenC: i have a patch for the buslogic stuff, i need to find a way to test it though
[05:39] <mjg59> zul: Cool
[05:41] <BenC> buslogic == vmare fix?
[05:42] <zul> yep..i added a struct for hotplug it seems the logical thing to do
[05:43] <zul> based on previous examples
[05:44] <BenC> fabbione: cool, thanks
[05:44] <BenC> my vmware install is v5, so I can't test it
[05:46] <Yagisan> I have vmware 5.5beta
[05:46] <Yagisan> want a copy ?
[05:48] <mjg59> Blah.
[05:48] <zul> sure...just send me a key or something
[05:48] <mjg59> Suck.
[05:49] <mjg59> It looks like we need to break ABI if we want these controllers to work
[05:49] <BenC> Yagisan: bug shows in vmware v4
[05:49] <mjg59> (Which includes bsaically everything made by HP at the moment)
[05:49] <mjg59> Sorry, my fault. I should have noticed this earlier.
[05:49] <zul> meh...i have a key for vmware4
[05:49] <BenC> mjg59: well, if it's that bug a deal, we will break it
[05:49] <mjg59> They work if you boot with the card in, but there are no events for insertion/deletion
[05:49] <BenC> s/bug/big/
[05:49] <Yagisan> BenC: I have 4.5.2 somewhere too
[05:50] <BenC> I think supporting cardbus on a large range of laptops qualifies as worthy of abi breakage
[05:50] <Yagisan> vmware 5 keys work in 5.5beta - that's part of the deal of being a beta tester
[05:50] <BenC> Yagisan: A copy of that would be nice, if it's not too much trouble
[05:53] <zul> Yagisan: same here
[05:53] <zul> lunch time
[05:56] <mjg59> BenC: Mailed
[05:56] <BenC> mjg59: the ABI breaker?
[05:56] <mjg59> Yeah
[05:56] <mjg59> The break is in cs.c
[05:57] <BenC> ok, thanks
[05:57] <BenC> btw, did you resend a second sk98lin patch?
[05:57] <BenC> I only got one
[05:57] <BenC> the first one
[05:58] <mjg59> Hrm. I did.
[05:58] <mjg59> The only difference was that -Ia/drivers was replaced with -Idrivers in the EXTRA_CFLAGS statement
[06:03] <fabbione> BenC: we need to add an extra package to upload when we break the ABI
[06:03] <fabbione> BenC: klibc B-D
[06:03] <Yagisan> heh - I did it again. linux-source-2.6.12_2.6.12-8.13 again failed to build in pbuilder - cites "lack of space"
[06:04] <fabbione> Yagisan: i blame pbuilder
[06:05] <Yagisan> fabbione: at least I have a log now
[06:05] <mjg59> BenC: Did you get the patch I just mailed you?
[06:08] <Yagisan> I'll point pbuilder at a 600GB RAID array, start it up, and go to bed. If it isn't done by the time I get up - I'll file a bug on pbuilder.
[06:08] <BenC> mjg59: not yet, I did get the pcmcia patch though
[06:09] <mjg59> BenC: Yes, that's the one I sent
[06:09] <mjg59> Should I resend the sk98lin one?
[06:10] <BenC> nah, I can just add your change manually
[06:11] <mjg59> Ok
[06:13] <BenC> I get spurious a's in my stuff too, I can deduce that you use vi :)
[06:25] <BenC> mjg59: are you sure the change to cs.c breaks the ABI?
[06:26] <BenC> the change is to socket_setup(), which is a static function
[06:26] <mjg59> BenC: Sorry, I should have been clearer. It adds a new callback to struct pcmcia_socket (see ss.h)
[06:26] <mjg59> So that changes the version
[06:27] <BenC> ah, ok
[06:39] <BenC> zul: ping
[06:43] <mkrufky> jbailey: fedora kernel people dont like my tree-merge solution, RE: missing dvb headers.... have you ever heard from the original bug poster?
[06:43] <mkrufky> jbailey: im hoping to get those moved into /include/linux/dvb .... hopefully for 2.6.15
[06:44] <BenC> mjg59: does the pcmcia fix apply to bug 15734, or is that bug a dup of the one this fixes?
[06:44] <zul> BenC: yo
[06:45] <mjg59> Should be unrelated
[06:45] <BenC> zul: you have sk98lin in your tree, right? So I don't need to merge this directly?
[06:45] <BenC> apply directly I mean
[06:45] <BenC> mjg59: ok
[06:45] <BenC> what bugs is it
[06:45] <mjg59> BenC: Don't have the number to hand, but it bites me here
[06:46] <zul> BenC: it will be going in tonight when i get home, should i remove the other yukon driver patch?
[06:46] <BenC> zul: yeah, I'm dropping sky2 completely
[06:46] <mjg59> 15196 looks likely, 15083 certainly is
[06:46] <BenC> if you pull it from your tree, even better, so I can just merge and take care of both
[06:47] <zul> BenC: ah so ill add it tonight, im just doing a build now to make sure everything is hunky dory
[06:47] <BenC> zul: thanks
[06:48] <BenC> I plan on making tomorrow prep day for upload on Thurs
[06:48] <BenC> just FYI
[06:48] <zul> ok..ill commit it tonight then ;)
[06:48] <mjg59> BenC: One more easy patch for you, possibly a couple of more awkward ones
[06:48] <mjg59> (won't break ABI)
[06:50] <BenC> mjg59: ok, I'm going to take those bugs, mark 15196 a dupe of 15083, and mark 15083 PEND
[06:52] <mjg59> Ok, cool
[07:24] <zul> whoops
[07:26] <mjg59> Hurrah!
[07:26] <mjg59> I may have found the solution.
[07:27] <BenC> pcmcia?
[07:29] <mjg59> PCMCIA breaking hibernate
[07:29] <mjg59> I'm afraid you're stuck with the ABI breakage :)
[07:29] <BenC> damnit :)
[07:32] <jbailey> mkrufky: Ah, okay.   Fixes reboot on HP laptops without affecting anyone else (I had one report of a desktop that didn't reboot with the reboot-thru-bios patch - this one should only hit affected machines)
[08:16] <Mithrandir> : tfheen@rookery ~ > umask
[08:16] <Mithrandir> 002
[08:18] <Mithrandir> fabbione: it looks sane to me
[08:31] <jbailey> BenC: Do you think it's safe to merge 10307 and 9115?
[08:46] <mkrufky> jbailey: looks like it's safe to move the headers... i just worked it out with the dvb maintainer
[08:46] <mkrufky> we should probably have them (officially) moved by 2.6.15
[08:46] <jbailey> mkrufky: Cool.
[08:46] <jbailey> mkrufky: If you have a list of what headers are moving where, I can take care of it in Breezy.
[08:47] <fabbione> Mithrandir: well the commit you did locked the archive
[08:47] <jbailey> mkrufky: No chance of sneaking it in for 2.6.14?  It's less invasive than the other crap that went in to -rc1
[08:47] <mkrufky> those 5 .h files in /drivers/media/dvb/dvb-core
[08:47] <jbailey> -rc2, rather
[08:47] <fabbione> Mithrandir: remember tha scp/sftp needs umask very eary
[08:47] <fabbione> early even
[08:47] <mkrufky> jbailey: I dont wanna push Linus' buttons
[08:48] <mkrufky> and... there are some out-of-tree dvb drivers that still depend on them to be in the current location
[08:48] <jbailey> mkrufky: 'kay.  Where will they go?
[08:48] <mkrufky> include/media/dvb
[08:49] <jbailey> include/media?
[08:49] <jbailey> A new subdir?
[08:49] <mkrufky> checking.....
[08:49] <jbailey> Maybe include/linux/media or somethin
[08:49] <jbailey> mkrufky: Is there another channel I should join?
[08:50] <mkrufky> nah, i took care of this over the linux-dvb mailing list
[08:50] <jbailey> mkrufky: Right now there's stuff in /usr/include/linux/dvb
[08:50] <mkrufky> but the applicable channel is #linuxtv
[08:50] <jbailey> Well, I'm not in a rush to add windows 76 on my irssi. =)
[08:50] <mkrufky> heh
[08:51] <mkrufky> looks like ur're right... that directory doesnt exist
[08:51] <mkrufky> i guess johannes wants to create the new directory
[08:51] <fabbione> Mithrandir: i do set the umask from .bash_profile, because i think sftp doesn't load bashrc
[08:51] <mkrufky> jbailey: apparantly this has already been the plan, i just kicked it with a little jumpstart, thanks to you
[08:51] <mkrufky> hang on, i will show you the email thread
[08:52] <jbailey> mkrufky: Tx.
[08:52] <jbailey> If they're going under /usr/include/linux/dvb, I can do this no prob.
[08:52] <jbailey> If he wants to create a new subdir, I need to wait for the flamewar, sadly.
[08:53] <mkrufky> hmm
[08:53] <mkrufky> would it cause any harm if u put them in include/linux/dvb ?
[08:53] <mkrufky> i doubt it.
[08:53] <jbailey> mkrufky: None at all. =)
[08:53] <jbailey> mkrufky: 'cept that if nothing is going to look for them there...
[08:53] <mkrufky> heh true
[08:53] <jbailey> That's why I'd rather drop them into wherever they're going to wind up eventually.
[08:54] <mkrufky> well, i wouldnt start up a flame war just yet
[08:54] <mkrufky> http://linuxtv.org/pipermail/linux-dvb/2005-September/004861.html
[08:54] <jbailey> But I imagine that there'll probably be some resistance to adding another directory to /usr/include from the kernel folks.
[08:54] <jbailey> hmm
[08:54] <mkrufky> ya maybe it makes sense to wait on it for now
[08:55] <jbailey> Dude, I see the words "are considered half-private i.e. not for userspace"
[08:55] <mkrufky> and tell your users to use the tree-merging scripts instead, as a temporary workaround
[08:55] <mkrufky> yes..... thats the same as any other kernel headers
[08:55] <mkrufky> but u see, those headers are needed for v4l compile , which is kernel space
[08:55] <jbailey> Is it a kernel module?
[08:55] <mkrufky> v4l is a set of kernel modules
[08:55] <jbailey> Hmm.
[08:55] <mkrufky> and so is dvb
[08:56] <mkrufky> ivtv is NOT a kernel module
[08:56] <jbailey> Are those going to just be integrated eventually?
[08:56] <mkrufky> they are already integrated
[08:56] <mkrufky> the only difference is:
[08:56] <mkrufky> users find themselves updating their v4l / dvb drivers to take advantage of support for new hardware
[08:57] <jbailey> Oh, hmm.
[08:57] <mkrufky> you see, i just wrote all these drivers for new hardware that came out last year
[08:57] <mkrufky> unfortunately, due to kernel release cycle, these drivers wont be available in a mainline kernel until 2.6.15
[08:57] <fabbione> BenC: ping?
[08:57] <jbailey> =P
[08:57] <mkrufky> so many users want to play
[08:57] <mkrufky> so they get cvs
[08:58] <mkrufky> now do u see ?
[08:58] <jbailey> I do.  It sounds very much like problem we can't solve.
[08:58] <mkrufky> no
[08:58] <mkrufky> it is easily solved
[08:59] <mkrufky> the user gets newer drivers from cvs
[08:59] <mkrufky> simple as that
[08:59] <jbailey> benc, fabbione: What do we currently do for folks who want to compile their own out-of-tree kernel drivers?
[08:59] <mkrufky> about the missing headers, until we standardize the final location, the tree-merging scripts will suppice as a temporary workaround
[08:59] <mkrufky> s/suppice/suffice
[09:00] <jbailey> Right.  But whatever mechanism we provide for other kernel modules to be built out-of-tree should also be available for these things.
[09:00] <jbailey> That might provide some hints for an esaier solution than the tree-merging scripts.
[09:00] <jbailey> The userspace headers that I provide in linux-kernel-headers have all of the #ifdef KERNEL bits ripped out of them.
[09:01] <jbailey> They can't be used for compiling kernel modules at all.
[09:01] <mjg59> BenC: Fix for 13382 just emailed to you
[09:01] <mjg59> Uh, 13882
[09:01] <fabbione> jbailey: we usually hand them a nice piece of RTFM :)
[09:02] <mkrufky> heh
[09:02] <fabbione> mjg59: re 13506...
[09:02] <fabbione> ahci is a scsi module...
[09:02] <fabbione> why should it land in sata?
[09:02] <mkrufky> the tree-merging scripts do more that just fix this header problem
[09:02] <mkrufky> there are other (non-critical) dependencies that v4l has in dvb-kernel that is necessary fro hybrid analog/digital capture cards
[09:03] <mkrufky> oh, wait... it all just clicked...
[09:03] <mjg59> fabbione: It's not a SCSI module. It's a sata one.
[09:03] <mkrufky> jbailey: did you at first think that v4l was userspace?!?
[09:03] <jbailey> mkrufky: Yes.  If I had known it was a kernel module, I would've asked Fabio the question earlier and not gone any further with it. =)
[09:03] <mkrufky> aaah
[09:05] <fabbione> mjg59: ok added.. but i have no way to ensure it's loaded before ata_piix
[09:05] <mjg59> fabbione: Well, we'll have to work that out later
[09:05] <mjg59> That can be handled in userspace
[09:05] <fabbione> mjg59: yup
[09:05] <fabbione> but there is no much time to do it
[09:06] <fabbione> so i rather suggest we talk with Kamion
[09:06] <jbailey> Do I smell more initramfs magic?
[09:06] <mjg59> jbailey: Sadly so
[09:06] <jbailey> Greeat.
[09:06] <mjg59> jbailey: Actually, probably module-init-tools magic. But it'll need to go in initramfs.
[09:07] <mjg59> jbailey: We just need a modprobe.d that attempts to load ahci before ata_piix
[09:07] <jbailey> fabbione: Which which FM shall I tell them to read when I smack this bug report with it?
[09:07] <jbailey> mjg59: 'attempts to'?
[09:07] <mkrufky> jbailey: so, i take it, that now that you know the true story... that ubuntu will frown upon such cvs module updates?
[09:07] <mjg59> jbailey: Well, it may fail
[09:07] <jbailey> mjg59: So anyone with ata_piix will have a stale ahci lying around?
[09:07] <mjg59> jbailey: It can always attempt to rmmod it afterwards :)
[09:07] <jbailey> mkrufky: No idea.  It means that I'm not worried about it for the userspace headers. =)
[09:08] <mjg59> Actually, I dunno if that would work
[09:08] <mjg59> jbailey: It's better to have a stale ahci module than non-working systems, I think
[09:08] <jbailey> mkrufky: That's why I'm asking Fabio which manual we send them to when they want to do their own modules?  Between that and the tree merging scripts, hopefully they'll sort it out.
[09:08] <fabbione> jbailey: it's called README + Makefile + Kbuild
[09:08] <fabbione> jbailey: seriously... modules that are done properly use kbuild
[09:09] <fabbione> if they use kbuild users needs only the headers for their running kernel and the correct gcc
[09:09] <mjg59> jbailey: There are 4 Intel bridges that will work with *one* of ata_piix or ahci
[09:09] <mjg59> And have identical PCI IDs
[09:09] <jbailey> fabbione: Which package is kbuild in?
[09:09] <mjg59> Actually, that's probably not true. ata_piix will probably drive them most of the time
[09:09] <jbailey> mjg59: 'kay.  Hmm.  Right now I'm just copying modprobe into the initramfs, and not the config files.
[09:10] <mjg59> jbailey: Yeah. We'll work something out.
[09:10] <jbailey> mjg59: Do y ou think I should also take all of /etc/modprobe.d ?
[09:10] <mjg59> jbailey: Not sure. Scripts there may call stuff that you don't have.
[09:10] <fabbione> jbailey: linux-headers.. it's kernel build system :)
[09:11] <fabbione> jbailey: but once you install the headers for your specific kernel
[09:11] <fabbione> you also automatically get the generic and kbuild
[09:11] <mjg59> BenC: Have we got the Apple touchpad driver?
[09:12] <mkrufky> jbailey: ah, gotcha
[09:13] <mkrufky> jbailey: this is exactly why i will backport the newer v4l/dvb code for the dapper kernel... hopefully users wont need to mess with cvs if all the latest support is already included in ubuntu's kernel
[09:14] <Mithrandir> fabbione: anyway, is it correct now?
[09:15] <fabbione> Mithrandir: yes.. thanks
[09:15] <fabbione> at least i could commit
[09:15] <jbailey> mkrufky: Ah, cool.  I expect that it's quite late for getting an update into breezy with less than a month to ship.
[09:16] <jbailey> mkrufky: I'll let you sort that out with BenC though.
[09:17] <jbailey> mkrufky: I see that the kernel-headers-2.6.12-8 package does have an include/media directory
[09:17] <jbailey> So this all makes sense now. =)
[09:18] <jbailey> Getting the headers into there for Breezy is probably quite doable to keep everyone happy.  (Again, it needs to go to BenC)
[09:19] <mkrufky> ah, cool
[09:19] <mkrufky> it DOES have include/media
[09:20] <mkrufky> but not include/media/dvb
[09:20] <mkrufky> (that is where they will end up going)
[09:20] <BenC> mjg59: don't think so
[09:20] <mkrufky> fabbione told me that he welcomes updates like i've mentioned, but yes, it probably IS too late for breezy
[09:21] <mkrufky> although if you guys are in fact interested, I can probably have a patch ready by tomorrow (or the next day)
[09:21] <fabbione> BenC: i did commit fixes for 14736 and 13506
[09:21] <fabbione> BenC: the former needs a full test build on ppc
[09:21] <fabbione> the latter on all arches
[09:21] <mjg59> BenC: Want me to find the diff for you?
[09:21] <fabbione> or at least ppc, i386, amd64 and ia64
[09:23] <BenC> fabbione: thanks
[09:23] <BenC> mjg59: yes, please
[09:23] <fabbione> BenC: no problem
[09:24] <BenC> dpatch is really slow for taking in a lot of small patches
[10:27] <jbailey> mjg59: Hey, did you ever make it possible for usplash to handle input text? =)
[10:27] <mjg59> I didn't
[10:27] <jbailey> I have a wishlist bug with a patch attached for encrypted root. =)
[10:27] <mjg59> Haha.
[10:27] <mjg59> Prefix it with usplash_write "QUIT"
[10:28] <jbailey> Sweet, that'll do nicely. =)
[10:28] <jbailey> usplash_write "FOAD"
[11:40] <mjg59> BenC: Just sent you a patch to fix http://bugzilla.kernel.org/show_bug.cgi?id=3927
[11:40] <mjg59> (Well, "fix")
[11:47] <mjg59> BenC: I've sent you a patch for #7904 (apple trackpad driver)