[04:30]  * Linden940 is away: going to go into the land of never mind this is not the place to say =P


[18:15] <PaulW2U> pleia2: need any help like copying to wiki?
[18:31] <pleia2> PaulW2U: yes please!
[18:32] <PaulW2U> ok, will start shortly
[18:55] <PaulW2U> pleia2: all done
[19:56] <pleia2> thanks
[20:11] <pleia2> added all the stats
[20:11] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue489
[21:00] <PaulW2U> editorial review done
[21:00] <pleia2> thank you :)
[21:01] <PaulW2U> and fixed a link before Unit193 got to tell you it was broken :)
[21:02] <pleia2> hehe
[21:02] <pleia2> I'll need to release in an hour or so before I head out for the evening
[21:02] <pleia2> east coast is messing up my schedule ;)
[22:30] <pleia2> publishing now
[22:38] <pleia2> almost forgot to mention! Jane Silber mentioned UWN in her keynote at UbuCon Europe :) it was really nice
[22:38] <pleia2> (I'll mention this in my blog post about the event... when I finally write it)
[22:38] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 489 for the week November 21 - 27, 2016 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue489


[02:57] <bluefoxicy> why is my / ext3?
[02:57] <bluefoxicy> ~$ cat /etc/fstab |grep ext4
[02:57] <bluefoxicy> UUID=10f59859-5e33-4277-a7d2-323447f54df7 /               ext4    defaults,errors=remount-ro,relatime 0       1
[02:57] <bluefoxicy> UUID=b574cf52-432a-4c2a-8742-effe21dbf760 /home           ext4    defaults,relatime        0       2
[02:58] <bluefoxicy> ~$ cat /proc/mounts |grep ext3
[02:58] <bluefoxicy> /dev/disk/by-uuid/10f59859-5e33-4277-a7d2-323447f54df7 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
[03:09] <TheMuso> /c/c
[07:30] <ogra> urgh, wha there a decision in debian to use /srv by default across the board ?
[07:30] <ogra> *was
[07:30] <TheMuso> ogra: For what?
[07:31] <ogra> well, tftpd-hpa defaults to it for tftp serving with the latest release
[07:31] <ogra> i was wondering if there is a general change
[07:31] <ogra> which would surprise me
[07:32] <TheMuso> ah ok
[07:32] <liw> that sounds like an excellent question for #debian-devel :)
[07:32] <ogra> gah, bug 84615
[07:34] <pitti> Good morning
[07:34] <ogra> the evil thing in tftpd-hpa is that they changed *both* defaults, it runs standalone now *and* not from inetd anymore ...
[07:35] <ogra> given that it doesnt carry a config file but was configured in inetd.conf thats pretty bad
[07:40] <StevenK> ogra: /srv == win
[07:40] <ogra> no
[07:41] <ogra> StevenK, so apache should use /srv/www now ?
[07:41] <liw> I prefer /srv/http, but I also think it's a local admin decision; http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
[07:42] <StevenK> ogra: Well, I actually configure Apache to pull from directories underneath /srv
[07:42]  * ogra wonders what all the admins out there would say if it suddenly did, breaking all the setups that use the default config :P
[07:42] <StevenK> But yes, what liw said. It's a local admin decision.
[07:42] <ogra> right
[07:42] <ogra> and the directory should stay clear from defults
[07:42] <ogra> *defaults
[07:43] <StevenK> ogra: I'm unsure about if the default should be somewhere under /var, or what it currently has, under /srv
[07:44] <ogra> var is variable system data, isnt it ?
[07:45] <liw> "However /srv should always exist on FHS compliant systems and should be used as the default location for such data."
[07:45] <StevenK> ogra: And /srv is data that is served by the system, so ...
[07:45] <ogra> srv is a nice concept to give admins more freedom, but essentially i think system default setups shuld stay out of it
[07:45] <liw> the FHS is clear that /srv should be the default location
[07:46] <ogra> "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done."
[07:46]  * ogra doesnt find that clear or even thought to the end
[07:47] <liw> I'm sure the FHS committee would accept reasonable arguments for change
[07:47] <ogra> an you think i would move people to a consensus ?
[07:47] <liw> certainly
[07:47] <ogra> looks to me like it was argued on before and there simply was no agreement
[07:48] <liw> if nothing else, you could push them all to dislike you and so have a consensus to vote against you? :)
[07:48] <StevenK> Hah
[07:48] <ogra> which reads to me like "no real *standard* could be defined"
[07:49] <liw> I haven't studied the history /srv, but I assume this happened the way fhs and similar standards are developed
[07:49] <ogra> well, to me a standard means there is "agreement how we all do it" ...
[07:49] <liw> i.e., people felt that /var was a bad location for things like http web roots (read: not easily shareable between hosts) and proposed a change
[07:50] <liw> so as a first step, /srv was invented and then the committee will wait a few years to see if it gets popular and if so, how it gets used
[07:50] <liw> before they make further changes
[07:50] <ogra> right, i dont say thats bad ... as long as there is a clear definition how /srv has to look like
[07:50] <ogra> else you end up with per distro chaos ... that defeats the purpose of easy portability
[07:51] <ogra> and given that there is no such definition yet it should not be used for default setups imho
[07:52] <liw> *shrug* the standard won't (and shouldn't) encode a structure before it has been tried in practice
[07:52] <ogra> heh, catch 22 ?
[07:53] <liw> not really, as long as people don't insist the FHS tell them in detail the location of every file and distros have a little bit of courage to try new things occasionally :)
[07:53] <ogra> i dont want to be told about files in detail ... but a rough definition about the substructure would be helpful
[07:54] <liw> I'm sure you'll find it in a future version of the fhs
[07:54] <liw> meanwhile, you can help decide what is the best substructure :)
[07:55] <ogra> well, the by protocol approach is fine with me ...
[07:55] <ogra> in my specific case i'm just running into a prob with tftpd-hpa which changes two setups at the same time
[07:56] <ogra> it ignored the former configuration (inetd.conf) and at the same time switches its default path
[07:56] <liw> that'd probably be a bug in that package
[07:56] <ogra> *ignores
[08:31] <Hobbsee> X really doesn't handle two monitors of different aspect ratios well, does it?
[08:32] <Hobbsee> gdm keeps throwing itself against the wall when you try
[08:32] <ogra> it does fo my monitor
[08:32] <lifeless> Hobbsee: that may have more to do with gdm
[08:32] <liw> X might. gdm perhaps doesn't.
[08:32] <Hobbsee> hm, could well be gdm
[08:32] <pitti> Hobbsee: is it similar to https://bugs.freedesktop.org/show_bug.cgi?id=22580 ?
[08:33] <ogra> (1900x1200 plus 1280x800 if i attach it to my laptop)
[08:33] <Hobbsee> (and 1024x768 looks painful on a 21.5 inch 16:9 monitor, incidently)
[08:33] <pitti> no, it's recent X trying to be too clever
[08:34] <Hobbsee> pitti: ah yes, i see that too
[08:34] <pitti> I have an internal LVDS (docked, closed, ignored) and an external TFT
[08:34] <pitti> and X comes up at 1024x768 on both now
[08:34] <Hobbsee> (when mirroring the display)
[08:34] <Hobbsee> yep
[08:35] <Hobbsee> turning off mirror mode lets you select the higher resolutions, though
[08:35] <pitti> sure, in my X session I can do the right thign (disable LVDS, use native resolution on DVI)
[08:35] <Hobbsee> just when you actually log out and back in to use them, gdm blows up
[08:35] <pitti> doesn't blow up here, but keeps switching modes
[08:36]  * ogra can use his 24" monitor just fine with the laptop, but X dies horribly if i attach my 42" TV
[08:39] <StevenK> Argh, now the blocking on ocaml transition is causing headaches for the rpm transition
[08:40] <ogra> Riddell, pitti, bug 190905says dnsmasq is in main, i dont see it there ?
[08:41] <pitti>    dnsmasq |     2.49-1 |        karmic | source
[08:41] <ogra> oh, ok
[08:41] <StevenK> ogra: The source is, the binary isn;t
[08:41] <pitti> ogra: dnsmasq-base is in main, the full dnsmasq binary isn't
[08:41] <StevenK> s/;/'/
[08:41] <pitti> nothing needs it
[08:44] <StevenK> Oh, bah, it's worse.
[08:45] <StevenK> Anything requiring dose2 can't be built since libdose2-ocaml can't be installed since librpm4.4 and librpm0 conflict, and I can't sync dose2 since it's blacklisted since the Debian ocaml maintainers don't want karmic transitioning.
[09:13] <directhex> Hobbsee, depends on how your graphics driver decides to present them
[09:13] <directhex> Hobbsee, at work i have a 1600x1200 secondary and 1920x1200 primary. gdm displays only on the primary
[09:14] <StevenK> pitti: So, would it be a bad thing to merge ekiga from Debian? (They have 3.2.5, and we have 3.2.0)
[09:24] <Hobbsee> directhex: right.  It dosent' seem to be having a problem displaying only on one monitor - just both resolutions are wrong
[09:24] <directhex> i don't have that issue
[09:25] <directhex> vertical res matches though, if that makes a diff
[09:33] <\sh> moins
[09:34] <\sh> evand: WTF is a "Ubiquity Contributor Agreement"? (And I think you mean Ubiquity as in live cd installer)
[09:40] <\sh> and why should someone sign this when the source is GPL2 and all contributions to this source are falling under that license, too?
[09:41]  * ogra points \sh to http://vdict.com/ubiquity,7,0,0.html
[09:42] <ogra> "omnipresent" :)
[09:43] <\sh> ogra: and what does it have to do with a) licensing a software and b) signing another document which grants the same rights? (minus this very strange patent paragraph)
[09:43] <ogra> it means that you agree this license applies *across the board*
[09:43] <ogra> i would say
[09:44] <ogra> (some native speaker may correct me)
[09:45] <ogra> s/license/agreement/
[09:46] <evand> \sh: yes, ubiquity the live CD installer.  It's a requirement per http://www.canonical.com/contributors .  My understanding of the reasons we require people to sign it are the two I outlined in that email.  I can put you in touch with a lawyer who can better elaborate on the details if you don't find my explanation sufficient.
[09:47] <ogra> oh
[09:47]  * ogra didnt know we had that
[09:47] <ogra> (for ubiquity)
[09:48] <\sh> evand: so what you are saying is: if someone is using the software, which I contributed to, not according to the GPL2 license, you will hunt them down like gplviolations?
[09:48] <\sh> s/you/Canonical/?
[09:49] <kamaln> Hi, can i discuss Ubuntu package development here?
[09:49] <evand> \sh: I think that's a question better put to our legal counsel.  I have a very limited understanding of the law and the plans of our legal department.
[09:50] <\sh> evand: please...would you forward this to your legal department? I really don't understand the usecase behind such an agreement :)
[09:52] <evand> \sh: If you could ask specific questions to Amanda (who's email address I'm about to private message you), I'd greatly appreciate it.  If I just send her an email myself saying your confused on why this is necessary, that leaves having to formulate an unnecessarily broad answer.
[09:52] <evand> that leaves her*
[09:52] <maxb> kamaln: You can, but be aware that this channel is primarily concerned with packages in the 'main' component - For 'universe' packages, including new packages, #ubuntu-motu is more appropriate
[09:52] <\sh> evand: will do
[09:53] <evand> \sh: Thanks, and apologies for the confusion.
[09:53] <evand> Legal issues are not my strong suit.
[09:53] <\sh> evand: no problem...:)
[09:54] <kamaln> maxb: what is meant my 'main' component..? Infact, I am developing a new package..so is it better to approach #ubuntu-motu
[09:54] <pitti> StevenK: not at all
[09:55] <maxb> kamaln: All new packages start out in 'universe', so yes, #ubuntu-motu is the right place
[09:56] <evand> kamaln: https://wiki.ubuntu.com/UbuntuDevelopers should help to explain the difference between motu and core-dev (this channel).
[09:57] <kamaln> evand: thanks..:-)
[10:01] <cjwatson> \sh: the FSF does exactly the same thing for contributions to GNU projects, FWIW
[10:06] <directhex> copyright assignment?
[10:09] <azeem> cjwatson: I believe the FSF explicitely says it will only license the assigned copyright under FLOSS licenses/GPL
[10:09] <cjwatson> well, yes, that's true. I meant copyright assignment in general
[10:10] <cjwatson> directhex: only for a few projects that we started, not for the whole of Ubuntu or anything, don't worry
[10:10] <azeem> (just mentioning, because you said "exactly the same thing"
[10:10] <azeem> )
[10:10] <\sh> cjwatson: so, I could give my copyrights to another entity (which is the FSF), why should I do that?
[10:11] <directhex> i believe a common alternative is to allow non-assignment as long as contributions are MIT/X11
[10:11] <cjwatson> the usual reason for copyright assignment is that it means that in case of violation it's actually possible to pursue violators; in many jurisdictions one cannot bring a case unless one has standing
[10:11] <directhex> \sh, essentially because it makes it easier for them to fight legal battles, as they cal claim to be the infringed party in disputes.
[10:12] <directhex> \sh, or you can have severe problems when you DON'T, e.g. parts of scummvm are unrelicensable as their author died
[10:12] <directhex> \sh, as it happens, your reasoning is why the Go-OO patchset for OpenOffice.org exists
[10:14] <\sh> directhex: well, for that I have a last will where I can state what will happen to my copyrights, software or IP...
[10:15] <directhex> can, or do?
[10:16] <cjwatson> mm. I've actually had that problem myself in the past, I didn't really want to contact a developer's widow and say "excuse me, exactly what pedantic things can I do with your late husband's code"
[10:16] <\sh> directhex: I have ... I just need to add things every year I survived
[10:16] <cjwatson> seems ... tasteless somehow
[10:16] <directhex> cjwatson, very. but what's the alternative?
[10:17] <\sh> cjwatson: actually it's that situation companies do with people taking over someones property
[10:17] <directhex> cjwatson, the scummvm case is significant as it prevented proper resolution of a gpl violation problem
[10:18] <cjwatson> fortunately in the case at hand it basically worked out that I didn't need to worry about it for various reasons
[10:18] <directhex> afaik apache requires assignment too
[10:18] <directhex> a housemate received legal paperwork from the foundation when we were undergrads
[10:18] <\sh> actually most of the software which are in our archives and we contributed some self-made patches needs such an assignment then
[10:19] <cjwatson> depends where the patches go, but you'll certainly find that many upstream contributions require assignments, yes
[10:19]  * cjwatson is in the process of getting assignments sorted out for findutils, parted, grub2, and something else I've forgotten
[10:20] <directhex> i think there's some generally held legal minimum patchiness level required to say "this patch counts as a proper contribution and needs proper licensing"
[10:20] <directhex> i'm pretty sure i'm not in MythTV's AUTHORS file
[10:20] <cjwatson> it's subjective, I have seen such things stated but never a clear legal opinion on it
[10:21] <directhex> sounds like something waiting for case law
[10:21] <james_w> I've seen people say "this isn't a patch, but if you go to foo.c and change the comparison on line 95 this bug will go away. Can I avoid signing a copyright assignment please?"
[10:23] <directhex> technically that statement is true
[10:24] <liw> the threshold for what is copyrightable (and what is too trivial to be copyrightable) varies betwen jurisdictions, and sometimes within them too
[10:24] <liw> on the whole, copyright law is screwed up all over the world
[10:25] <\sh> well, if those assignments has a paragraph like: "A company/organization which violates the authors/contributors license will be sued by Us [where "Us" is someone else company/organization] to enforce the given license of the author/contributor. Any monetary solution to this charge will be shared among the Law Company, the author of the software and all contributors" this would make sense to me (not that I want any blood money)
[10:26] <\sh> btw..I just had a karmic problem unlocking the screensaver...it just waited there forever
[10:27] <cjwatson> me too last night, I was wondering if it was due to not having restarted after an upgrade
[10:27] <cjwatson> I had to kill gnome-screensaver
[10:28] <\sh> it was after todays update...and there was no restart required according to non-existent "Restart required notifier" :)
[10:33] <dpm> StevenK: regarding fbreader, I'd like to reply to upstream. Seeing that it will not be promoted to main, I'm guessing that the i18n work will not be done?
[11:20] <\sh> hmm...what does "You have N broken packages on your system. Please use the "broken" filter to detect them"? (Dialogbox of update-manager, without any hint where to set the "broken" filter)
[11:21] <azeem> maybe that's a message from synaptic
[11:22] <\sh> azeem: as it follows the "Install updates" of update-manager...I can't tell...but this message is very strange and will confuse people, at least it confuses me
[11:23] <\sh> and now, update-manager won't close after updating all selected packages..hmmm
[11:24] <\sh> now it's gone...after 1:30 mins
[11:40] <Laney> does sync blacklist block even manual syncs? I thought it was just for autosync
[11:41] <cjwatson> only autosyncs
[11:41] <cjwatson> err, wait, maybe not
[11:41] <Laney> or is autosync just a loop over the manual procedure?
[11:41] <cjwatson> no, manual syncs too actually. But anyone who can do a manual sync can edit the blacklist ...
[11:41] <Laney> sure
[11:42] <directhex> Laney, if you were me, would you 0ubuntu1 xsp and mono-tools?
[11:42] <Laney> getting emails from bug 387943
[11:42] <cjwatson> basically just a loop with a bit of extra reporting
[11:42] <Laney> directhex: what's the delay?
[11:42] <directhex> Laney, binary NEW
[11:43] <Laney> I'd wait
[11:43] <Laney> binary NEW isn't too slow, is it?
[11:43] <cjwatson> but in that case the blacklist is there for a reason and removing it does seem to merit some discussion
[11:43] <james_w> binary NEW in Debian?
[11:43] <directhex> james_w, aye
[11:43] <james_w> I didn't think they had one?
[11:43] <cjwatson> it's probably just that ftpmasters are at debconf :)
[11:43] <cjwatson> they do
[11:43] <directhex> james_w, binary NEW in ubuntu requires only beatings and/or beer
[11:44] <directhex> james_w, the ftp-master page doesn't distinguish - the ftpmasters actually do though
[11:44] <james_w> and that would indicate that the source was published, and so we could sync. Or do I misunderstand the process?
[11:44] <directhex> james_w, you may not access files uploaded to NEW
[11:44] <cjwatson> if the new binary packages went together with a source upload, then the whole upload stays in NEW
[11:44] <james_w> yeah
[11:44] <directhex> james_w, as some kind of defence against undistributable source. or somesuch
[11:45] <james_w> an "new-binary NEW"
[11:45] <cjwatson> the queue never splits up .changes
[11:45] <james_w> "ah", I mean
[11:45] <james_w> I get it now
[11:46] <directhex> short version: long wait time
[12:06] <directhex> if openprinting-ppds contains an obsolete ppd-drop from a printer vendor, what's the best way to get it updated?
[12:08] <mvo_> \sh: uh, that is indeed confusing - could you mail me your /var/log/apt/term.log please?
[12:13]  * directhex dances in circles, goes to file a bug, notices it just goes to tkamppeter anyway
[12:39] <tkamppeter> directhex, which PPDs are obsolete?
[12:40] <directhex> tkamppeter, kyocera. i can get a precise list of models if you give me a few mins
[12:41] <tkamppeter> directhex, OK.
[12:41] <tkamppeter> directhex: Unfortunately, I did not get Kyocera PPDs for years, so there are probably missing a lot.
[12:42] <directhex> how odd, there are more PPDs on here than in Kyocera's download
[12:43] <tkamppeter> directhex, can you tell me where I can find Kyocera's download?
[12:43] <tkamppeter> It can be that Kyocera does not have arbitrary old models in their download and the oldest models on OpenPrinting are perhaps older.
[12:44] <directhex> +Kyocera_FS-1118MFP_en.ppd
[12:45] <directhex> +Kyocera_FS-C5015N_en.ppd
[12:45] <directhex> +Kyocera_FS-C5025N_en.ppd
[12:45] <directhex> +Kyocera_FS-C8100DN_en.PPD
[12:45] <directhex> +Kyocera_KM-1820_en.ppd
[12:45] <directhex> +Kyocera_KM-C2520_en.PPD
[12:45] <directhex> +Kyocera_KM-C3225_en.PPD
[12:45] <directhex> +Kyocera_KM-C3232_en.PPD
[12:45] <directhex> those are the additions
[12:45] <ScottK> cjwatson: I did verify the debian-cd change you merged for me fixed the background problem on the Kubuntu Netbook ISO.  Thanks agian.
[12:46] <tkamppeter> directhex: are you listing the models which are missing in Kyocera's download or the ones which are missing on OpenPrinting?
[12:46] <directhex> tkamppeter, the latter
[12:47] <tkamppeter> So these are the newest models which need to get added?
[12:47] <tkamppeter> directhex: And where can I download the PPDs?
[12:47] <directhex> seems there are also some minor changes to old ones
[12:47] <cjwatson> ScottK: oh good
[12:47] <directhex> tkamppeter, bottom of http://www.kyocerasupport.co.uk/index/download_center.false.driver.FS1118MFP._.EN.html has a link
[12:48] <StevenK> cjwatson: Well, I'd like to remove dose2 from the blacklist, just so I can get this librpm4.4 mess cleaned up.
[12:49] <cjwatson> but won't it basically pull in the whole ocaml mess?
[12:49] <cjwatson> I thought that was the point of blacklisting all that stuff
[12:49] <StevenK> I'm just about to check that
[12:49] <Laney> I think we should go ahead with the transition anyway
[12:49] <cjwatson> i.e. I thought there were source changes in there that relied on the new ocaml
[12:49] <Laney> (OCaml)
[12:50] <StevenK> cjwatson: My other thought was doing -3~ubuntu1 which is -3, without the new ocaml
[12:50] <ogra> god, thses gpm popups are annoying
[12:50] <ogra> *these
[12:50] <Laney> it doesn't seem so bad, and there's a nice tool for helping with it
[12:50] <liw> ogra, hm?
[12:51] <ogra> liw, i get "your battery is fully charged" or "... discharging" as popunders since some days
[12:51] <liw> ogra, ugh
[12:51] <ogra> *huge* popunders with three buttons in a row
[12:52] <StevenK> Well, I wonder if Debian has completed the transition.
[12:52] <StevenK> It's been a month, after all.
[12:52] <StevenK> If they have, compiling a list of stuff to sync should be fairly simple.
[12:53] <tkamppeter> directhex: The PPDs are under MIT license, so I can update OpenPrinting ...
[12:54] <directhex> tkamppeter, i wouldn't have bugged you if they weren't Free :po
[12:54] <directhex> :p
[12:55] <tkamppeter> directhex, with OpenPrinting updated, Ubuntu Jaunty and higher would simply directly get them from OpenPrinting.
[12:55] <Laney> StevenK: They have, apart from one sourc epackage (see mail to u-d-d)
[12:56] <tkamppeter> directhex, about free licenses of PPDs, you can inform me about all PPDs offered for use with Linux, independent whether they are free or not, as in some cases I can contact the manufacturer.
[12:56] <StevenK> Laney: Ah, but it seems like they want to keep 3.11.0 in Karmic, and have 3.11.1 in Karmic+1
[12:56] <StevenK> Which makes me go argh
[12:57] <directhex> tkamppeter, i don't generally look at this stuff, unless an engineer appears out of nowhere to take my laserjet away & put an unsupported-in-jaunty kyocera 1118 in its place
[12:57] <Laney> well he asked if we should do the transition, and I said that I think we probably could and should
[12:58] <StevenK> I agree that we should, it makes headaches like the one I just found go away
[12:58] <tkamppeter> If the PPDs are redistributable but not free software (only vernatim redistribution) I can at least put them up on OpenPrinting, in the foomatic-db-nonfree package, and that is enough for Ubuntu auto-downloading the PPDs. If they are free, they get into foomatic-db and so also into Ubuntu.
[12:58] <Laney> StevenK: would be good if you could say as much in that thread then
[12:58] <directhex> tkamppeter, the only other printers i have access to generally are a Brother (so i get that frustrating ERROR problem on most print jobs) and a Toshiba (which works fine)
[12:59] <directhex> tkamppeter, i did get to tell a Canon salesperson they were smoking crack once, though, thanks to their laughable loonicks support
[13:01] <ogra> seb128, is ssh support in gvfs known to be broken atm ? my nautilus crashes if i try to sftp mount people.canonical.com
[13:02] <seb128> ogra, do you have ubuntuone-client-gnome installed?
[13:02] <Laney> WFM (tm)
[13:03] <seb128> ogra, ubuntuone is known to make nautilus crash at the moment so if you have it yes it's known
[13:04] <ogra> well, could i not ? its seeded :)
[13:04] <ogra> so yes, i have
[13:04] <ogra> thanks
[13:04] <seb128> ogra, you're welcome
[13:05] <seb128> ogra, nobody force you to have ubuntu-desktop installed, I don't ;-)
[13:05] <ogra> i want to eat our own dogfood ;)
[13:21] <ogra> kirkland, around ?
[13:25] <cjwatson> ogra: (ubuntuone's only a recommendation, you can remove it and still have ubuntu-desktop installed)
[13:26] <ogra> cjwatson, yeah indeed
[13:26] <ogra> given that my invite timed out anyway, i should probably do that
[13:43] <lool> ScottK: I think you tried pinging me over the WE but I forgot to go back to you
[14:04] <SteveA> I know suspend / hibernate is fragile generally... it was working find on this laptop running jaunty.  Now, with karmic, suspend and hibernate don't work.  The screen goes dark for a while when I ask it to suspend then a minute or so later I get the "enter password to close the screensaver" screen.
[14:04] <SteveA> should I file a bug?  against what package?
[14:04] <ogra> likely the kernel
[14:18] <hyperair> is anyone here familiar with gdk_window_get_frame_extents?
[14:20] <hyperair> hmm no wait, that's not the problem here.
[14:28] <hyperair> hmm for some reason my panel isn't a dock.
[14:30] <james_w> is there someone else doing NEW at the moment?
[14:33] <james_w> jdstrand: you perhaps?
[14:33] <jdstrand> james_w: I was trying to get to a few before slangasek came online, yes-- are you doing mondays now?
[14:33] <james_w> yeah, myself and slangasek split the day
[14:34] <james_w> I've no problem with you doing some though :-)
[14:34] <james_w> I'm just not sure what danger there is of collisions
[14:34] <jdstrand> james_w: I plan to do ltsp-cluster-lbagent, moovida* and qemu-kvm
[14:34] <james_w> great, thanks
[14:34] <james_w> I'll go for lunch
[14:35] <james_w> give me a shout once you're done and I'll do the rest
[14:35] <jdstrand> james_w: ok
[14:35] <james_w> thanks
[14:35] <jdstrand> np
[14:37] <Laney> does the i386 buildd call build-indep directly?
[14:39] <geser> Laney: IIRC it calls build while the other call build-arch (but better look at a build log to be sure)
[14:41] <stvo> window splitv
[14:42] <stvo> sry
[14:45] <pitti> hey stvo
[14:45] <pitti> stvo: trying weechat? :-)
[14:46] <ogra> pitti, is stvo who i think he is ?
[14:47]  * pitti engages long-distance brain reader
[14:47] <ogra> haha
[14:47] <pitti> ogra: confirmed with 89.234 probability
[14:47] <ogra> lol
[14:47] <stvo> lol
[14:47] <ogra> hi stvo, great to see you here
[14:47] <stvo> thx
[14:48] <stvo> ogra I'm testing your arm chroot
[14:48] <stvo> environment
[14:49] <ogra> nice :)
[14:49] <ogra> note that its not 100% reliable but good for poking around ... some syscalls are likely missing
[14:52] <kirkland> ogra: howdy!
[14:53] <ogra> kirkland, lool told me you migh be working on a spec that implements something like https://wiki.ubuntu.com/ARM/BuildEABIChroot
[14:53] <ogra> if thats true, is there any chance we see it in karmic ?
[14:54] <lool> ogra: No, kirkland is working on getting us qemu updates though
[14:54] <ogra> (i'm referring to the binfmt setup by default)
[14:54] <ogra> ah
[14:54] <lool> 11:49 < lool> I'm sure this can all be done when we refresh our qemu
[14:54] <lool> 11:49 < lool> I think kirkland has a spec on this
[14:55] <ogra> then i misunderstood the "all" in that sentence :)
[14:55] <kirkland> lool: ogra: hmm, i'm working on getting the new qemu-kvm project into karmic
[14:55] <kirkland> this project is the merger of the qemu and kvm code
[14:55] <lool> kirkland: Is this based on qemu 0.11?
[14:55] <kirkland> qemu plus the kvm acceleration bits
[14:56] <kirkland> lool: that's the target
[14:56] <kirkland> lool: 0.11 just hit Release Candidate
[14:56] <lool> Cool
[14:56] <ogra> cool, that at least gets us the eabi patches
[14:56] <kirkland> lool: that will make it into karmic
[14:57] <kirkland> lool: it was targeted at alpha3, but upstream slipped a little
[15:03] <jdstrand> james_w: I'm done
[15:03] <pitti> hah, fighting for sync karma? :-)
[15:04] <jdstrand> who me? nah, I just couldn't get to archive much on Friday
[15:04] <james_w> thanks jdstrand
[15:04] <jdstrand> sure :)
[15:15] <directhex> yay for james_w, one step closer to mono 2.4.2 in karmic
[15:31] <ScottK> lool: Thanks for checking back, it got taken care of already.
[15:38] <Ampelbein> hi there. whom should I poke when a NBS' dependencies is zeroed? In that case it's libgnokii3 where all dependencies on that are eliminated now.
[15:38] <Ampelbein> or is there some kind of automagic NBS removal?
[15:41] <james_w> Ampelbein: manual-automatic :-)
[15:43] <Ampelbein> james_w: so I poke you and you do it? sweet! ;-)
[15:44] <james_w> I've not done it yet
[15:44] <james_w> we'll see if I get down that far on the list today
[15:45] <Ampelbein> no worries... thank you for the info.
[15:48] <lool> kirkland: Ack I heard that during the release meeting
[15:49] <lool> kirkland: (ogra was rolling his own qemu 0.10 + patches to get some better ARM EABI support and was interested in having that in ubuntu which is why I pointed him at you)
[15:49] <lool> I'm using tip + patches
[15:50] <kirkland> lool: for tip, are you aware of https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream ?
[15:50] <ogra> well, there is more than the patches ... but if our qemu-arm could support eabi that would be a major step forward
[15:50] <ogra> i would still like to have a package i can easily install that enables binfmt
[15:51] <ogra> and disables it on package removal respectively
[15:52] <kirkland> ogra: lool: any reason why these patches aren't upstream in qemu?  we have a friendly qemu maintainer, we sponsored him to barcelona uds
[15:53] <ogra> kirkland, the patches are apparently
[15:53] <ogra> just not in our package
[15:53] <kirkland> ogra: oh, great
[15:53] <kirkland> ogra: then this will sort itself out very shortly
[15:53] <kirkland> ogra: in the mean time, see: https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream
[15:53] <kirkland> ogra: 0.11.50 is building there
[15:54] <ogra> nice
[15:54] <ogra> i'll try it out soon
[15:57] <andresmujica> do we have an ubuntu java or eclipse channel?
[15:58] <ogra> lool, kirkland, though for the chroot bits i would still need a statically build binary
[15:58] <ogra> just strikes me ...
[15:58] <lool> kirkland: I am aware of the PPA; thanks; I build tip by hand because I apply some non-mergeable patches on top of qemu
[15:58] <ogra> *built
[15:59] <ogra> kirkland, do you think it would be possible to roll a qemu-arm-static into our package ?
[16:00] <kirkland> lool: gotcha, good to know
[16:00] <kirkland> ogra: hrm, i don't see why not ...  do you have a diff that does this?
[16:01] <kirkland> ogra: curious, just wondering... why do you need a static build of that binary?
[16:01] <ogra> no, my package is totally badly built with its own copy of the qemu source and the patch inline
[16:01] <lool> ScottK: Cool, so these perl libs should soon be installable?
[16:02] <ogra> kirkland, what i do is: apply the eabi patches, build it statically, enable the interpreter in binfmt-support to match the magic of any armel binaries ... then i roll an armel chroot ... to exec armel binaries *inside* that chroot i need the x86 qemu ...
[16:03] <ogra> kirkland, which indeed wouldnt find its libs *in* the chroot
[16:03] <kirkland> ogra: right
[16:03] <ogra> with the static version i can just chroot into my bootstrapped root and move on
[16:04] <ScottK> lool: Right.  Thanks for the reminder (ugh).  No, it was another issue.
[16:04] <ogra> its extremely convenient
[16:04]  * ScottK looks into it.
[16:04] <lool> Eh :)
[16:04] <kirkland> ogra: agreed
[16:05] <lool> So it's libcompress-raw-zlib-perl which I can't upgrade due to the dep of libio-compress-zlib-perl
[16:07] <ogra> kirkland, in my package i essentially just do "./configure --prefix=/usr --target-list=arm-linux-user --static" in debian/rules, but i guess thats not proper enough for the actual package in the archive
[16:08] <kirkland> ogra: right, let me think on this some
[16:08] <kirkland> ogra: i'll talk to upstream too
[16:09] <ogra> thanks :)
[16:09] <kirkland> ogra: i might be able to add a binary package to the source package
[16:09] <kirkland> ogra: qemu-arm-static or something
[16:09] <kirkland> ogra: or qemu-static
[16:09] <kirkland> ogra: and just publish that one to universe?
[16:09] <ogra> that would be cool since it could also carry the proper postinst and prerm bits for binfmt
[16:09] <ogra> universe is totally fine
[16:10] <kirkland> ogra: would you open a wishlist bug against qemu to capture this?
[16:10] <ogra> yeah
[16:10] <kirkland> ogra: i'm tracking down a nasty ecryptfs right now
[16:10] <kirkland> ogra: so i guarantee i'm going to forget this otherwise :-D
[16:10] <ogra> no hurry
[16:20] <ogra> kirkland, bug 401782 is yours
[16:21] <kirkland> ogra: thank you sir!
[16:21] <ogra> no, thank you ! :)
[16:22] <kirkland> ogra: thank me when I finish the work :-)
[16:23] <ogra> heh
[16:23] <ogra> well, until then my hackish ppa package will do :)
[16:39] <ScottK> lool: They've combined several perl modules into one.  This is non-trivial.
[17:25] <RainCT> Keybuk: Hey. How does this look? http://revu.ubuntuwire.com/~rainct/mom.html
[17:26] <Keybuk> cute
[17:28] <cjwatson> RainCT: I'm sure it's not the point, but your data is perplexing - you seem to be using the primary UID on the signing key for "Last Uploader", rather than, say, Changed-By if it matches one of the UIDs on the key ...
[17:30] <RainCT> cjwatson: Seems like it's just running gpg and looking at the "Good signature from X" line. But hey, that's not my code! :)
[17:30] <Keybuk> cjwatson: patches welcome
[17:31] <Keybuk> cjwatson: in fact, I think you may have _written_ this patch in the first place ;-)
[17:31] <cjwatson> Keybuk: oh, I didn't think current MoM acted this way ...
[17:32] <cjwatson> I don't remember doing so? but that doesn't mean a whole lot
[17:32] <RainCT> Keybuk: The (new design) code is up on lp:~rainct/merge-o-matic/redesign for your merging pleasure :)
[17:33] <Keybuk> Jo Shields<EMAIL_ADDRESS>[17:33] <Keybuk> Uploader: Colin Watson<EMAIL_ADDRESS>[17:33] <Keybuk> (e.g. from current MoM output)
[17:34] <cjwatson> definitely wasn't me who wrote that patch, I don't recognise that code at all
[17:35] <Keybuk> RainCT: though that's a good point
[17:35] <Keybuk> RainCT: your code drops the distinction
[17:35] <cjwatson> anyway, current MoM doesn't act this way because for the upload in question changer == uploader
[17:35] <Keybuk> current MoM shows both the Changed-By *and* Uploader when different
[17:36] <Keybuk> yours only shows the Uploader
[17:36] <Keybuk> (who is generally a sponsor, not the person who made the change)
[17:36] <cjwatson> right
[17:36] <Keybuk> RainCT: looks like you haven't touched manual-status.py yet?  Would be good to have that in the same form
[17:36] <RainCT> Keybuk: Oops, right. My test with a single package isn't that helpful :)
[17:37] <Keybuk> RainCT: other than that it looks good
[17:37] <Keybuk> so if you can fix those two things, I'll be more than happy
[17:38] <RainCT> Keybuk: uhm, hat is that manual-status.py thing?
[17:44] <Keybuk> RainCT: produces https://merges.ubuntu.com/{main,universe,restricted,multiverse}-manual.html
[17:48] <andresmu1ica> i've lost X output completely with latest gdm update in karmic...  :/
[17:58] <pitti> andresmu1ica: "x output"?
[17:59] <andresmujica> pitti: black screen with everything working.. give a minute i've downgraded to gdm 2.26 and recovered X output.. upgrading again to confirm or deny it...
[18:03] <RainCT> Keybuk: can you please check if the uploader is displayed now?
[18:17] <andresmujica> pitti: not related to gdm, it seems a bug with kernel 2.6.31-1-generic it gives no X output .. but as we already passed it there's no problem at all.
[18:46] <kirkland> karmic sound issues?  i'm getting momentary pauses during mp3 playback;  tried numerous different players and sources
[18:47] <kirkland> dtchen: ^
[19:01] <ogra> kirkland, i had mine play at double speed on the weekend ... reboot fixed it
[19:02] <kirkland> ogra: heh
[19:02] <kirkland> ogra: i've rebooted a few times recenty
[19:02] <ogra> upgraded too ?
[19:03] <ogra> i first did an upgrade (which didnt ask for reboot) ...
[19:03] <ogra> and after the reboot it was actually working fine ...
[19:03] <ogra> i had the issue in all players, even tried mplayer and xine
[19:08] <RainCT> Keybuk: Should work now, but I can't test manual-status.py myself
[19:17] <slangasek> james_w: fwiw, it's perfectly fine for archive admins to sync packages directly instead of filing sync requests. :)
[19:18] <james_w> :-)
[19:18] <infinity> (Unless you really want a review or something)
[19:18] <infinity> (But then I'd take that OOB and just get it done quickly)
[19:50] <directhex> is ubuntu-meta maintained someplace in bzr?
[20:22] <slangasek> directhex: no, since most of the contents are autogenerated there hasn't been much need
[20:52] <rtg_> slangasek, do you have a moment to review my proposed addition of rfkill to wireless-tools ? http://kernel.ubuntu.com/~rtg/wireless-tools.diff
[20:58] <slangasek> rtg_: <squint> the diff looks fine, but why in the world is this now being done via a control device instead of via /sys?
[20:59] <slangasek> that really seems like a step backwards
[21:00] <rtg_> slangasek, it can be done both ways, but I guess /dev/rfkill is the preferred method for setting/retrieving state for all wireless devices.
[21:00] <slangasek> no, it can't be done both ways :)
[21:00] <slangasek> not in 2.6.31 - someone broke the /sys interface
[21:00] <rtg_> I thought it just moved
[21:01] <slangasek> well, they broke two things - 1) there's no longer a link to the rfkill interface from the /sys/class/net tree, 2) trying to toggle any rfkill interfaces through sys fails with "Operation not permitted"
[21:03] <nxvl> james_w: is there something in bazaar like svn debcommit?
[21:03] <rtg_> slangasek, for the acpi-support package the rfkill application should be sufficient for controlling rfkill state. do you want me to pursue what is wrong with the sysfs interface?
[21:04] <james_w> nxvl: what does that do?
[21:04] <rtg_> instead
[21:04] <nxvl> james_w: commits the changes and generates the comment from the changelog
[21:04] <james_w> debcommit doesn't do what you want?
[21:04]  * nxvl tries
[21:05] <nxvl> james_w: yes it does
[21:05]  * nxvl HUGS james_w
[21:05] <slangasek> rtg_: well, I'm getting a little sick of the interface moving every single release, and the acpi-support compatibility code becoming increasingly baroque :/
[21:06] <slangasek> rtg_: I thought the previous /sys interface was a very sensible one, and it seems like a bug to me that it's changed again
[21:07] <rtg_> slangasek, as well that may be, there is little I can do about it.
[21:07] <slangasek> rtg_: who's working on this stuff upstream?  maybe I can rant at them directly :)
[21:07] <slangasek> (anyway, surely it /is/ a bug that you can't change the state via /sys at all anymore?)
[21:08] <rtg_> slangasek, Johannes Burg is the guy that rewrote rfkill. I guess he'd be the best place to start. Perhaps on the<EMAIL_ADDRESS>list.
[21:08] <rtg_> s/Burg/Berg/
[21:08] <slangasek> rewrote - bah :)
[21:09] <slangasek> ok, I'll see what comes of prodding, thanks
[21:09] <rtg_> slangasek, well, the original version did had some serious problems from what I understand.
[21:19] <bannaN> I could be interested in contributing in the development of ubuntu, where do i start? What kind of skill-level is required?
[21:19] <azeem> bannaN: ask in #ubuntu-motu
[21:20] <cjwatson> bannaN: http://wiki.ubuntu.com/ContributeToUbuntu
[21:23] <bannaN> Kindy dont know where to start, who to ask, and how to join, and what kind of work-tasks is available for a person with my knowledge
[21:29] <cjwatson> bannaN: right, it's complicated (and we don't know either, because it depends so much on your interests and experience), which is why I gave you a page full of links that you can go and read :-)
[21:32] <bannaN> cjwatson: hehe, yeah, what i had in mind was maybe bugfixing, testing or something like that, dont know whats possible in the begining, and how tasks are asigned
[21:36] <cjwatson> bannaN: with some exceptions (for instance, people employed to work on Ubuntu often have things assigned to them), people generally take things for themselves rather than waiting to be asked
[21:36] <cjwatson> the process for fixing bugs is to find some bugs you think are interesting and send patches! :-) And http://wiki.ubuntu.com/SponsorshipProcess if you want to get those patches reviewed in a timely fashion
[22:01] <BUGabundo> hey dear devs
[22:01] <BUGabundo> pitti: were you who broke gtk on karmic with that patch for gfvs?
[22:04] <seb128_> BUGabundo, gtk and gvfs are really different things
[22:04] <BUGabundo> yeah I know
[22:04] <BUGabundo> just gluing some pieces
[22:04] <BUGabundo> haven't got my listchanges to work yet, after format
[22:04] <seb128_> BUGabundo, not really gluing no, gvfs has no user inferface and don't use gtk
[22:04] <BUGabundo> so knolage may be incomplete :)
[22:04] <seb128_> BUGabundo, and gtk doesn't use gvfs either
[22:05] <seb128_> BUGabundo, rather than trying to guess you should better describe your issue
[22:05] <BUGabundo> seb128_: not a single icon anywhere on my system
[22:05] <BUGabundo> err
[22:05] <BUGabundo> not _my_. any karmic, updated
[22:06] <seb128_> ?
[22:06] <BUGabundo> yofel: what was the package you mentioned?
[22:06] <yofel> seb128_: .xsession-errors tells us that it can't recognize the picture format
[22:06] <yofel> of the icon theme
[22:06] <seb128_> BUGabundo, "any", works for me
[22:06] <BUGabundo> seb128_: yes, really. no app icons, not icons on pidgin, on firefox, nothing
[22:06] <BUGabundo> just boxes with red cross
[22:06] <yofel> seb128_: like for example: ** (gnome-terminal:13296): CRITICAL **: failed to load icon 'lpi-translate': Format der Bilddatei unbekannt
[22:07] <seb128_> having english errors would be a good start
[22:07] <yofel> it's something along of: unknown picture format
[22:07] <BUGabundo> let me pastebin mine
[22:08] <BUGabundo> its in english
[22:08] <BUGabundo> $ pastebinit .xsession-errors
[22:08] <BUGabundo> http://paste.ubuntu.com/223031/
[22:09] <seb128_> BUGabundo, did you open a bug using apport?
[22:09] <BUGabundo> not yet
[22:09] <BUGabundo> I just came online
[22:10] <BUGabundo> and yofel confimed it, so I though I would ask around
[22:10] <seb128_> BUGabundo, what architecture do you use?
[22:10] <BUGabundo> before putting it on LP with no package
[22:10] <BUGabundo> x64
[22:10] <seb128_> yofel, you?
[22:11] <yofel> seb128_: yes, updated my system a few minutes before BUGabundo came and have the same issue
[22:11] <BUGabundo> hey kenvandine
[22:11] <seb128_> yofel, the question was "what arch do you use"?
[22:11] <yofel> oh, sry - amd64
[22:11] <BUGabundo> ahah
[22:12] <seb128_> k, could be amd64 specific
[22:12] <giles> yofel: I tuned in
[22:12] <BUGabundo> seb128_: package so I can file it ?
[22:12] <BUGabundo> humm notify OSD is gone too LOL
[22:12] <seb128_> BUGabundo, gtk+2.0
[22:12] <yofel> giles: what's your cpu-arch? x86 or x64?
[22:12] <BUGabundo> at least Volume one
[22:13] <BUGabundo> seb128_: Package gtk+2.0 does not exist
[22:13] <Ampelbein> BUGabundo: ? https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0
[22:13] <seb128_> libgtk2.0-0 if you want a binary package rather
[22:13] <giles> yofel: x64
[22:13] <BUGabundo> Ampelbein: tell that to my apport :)
[22:13] <seb128_> the issue seems amd64 specific
[22:13] <seb128_> I've no amd64 config to work on that though
[22:14] <BUGabundo> uploading now
[22:15] <BUGabundo> The collected information can be sent to the developers to improve the
[22:15] <BUGabundo> application. This might take a few minutes.
[22:15] <BUGabundo> ............................................................................................................................................................................
[22:15] <BUGabundo> never seen apport take soooooooo long
[22:16] <BUGabundo> I think it jammed :(
[22:19] <BUGabundo> back
[22:19] <BUGabundo> sorry, lost wifi
[22:20] <seb128_> BUGabundo, do you have a  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so ?
[22:21] <BUGabundo> $ ls  /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
[22:21] <BUGabundo> -rw-r--r-- 1 root root 23K 2009-07-20 18:12 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
[22:22] <seb128_> BUGabundo, ok, the amd64 build lacks the png loader for some reason
[22:22] <BUGabundo> https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/401938
[22:22] <BUGabundo> yofel: giles: feel free to sub
[22:23] <yofel> seb128_: the svg one is missing as well i think
[22:24] <BUGabundo> ohhh the bot is lagged 1min
[22:27] <BUGabundo> can someone set that to confirm, please?
[22:27] <seb128_> BUGabundo, what difference does it make?
[22:27] <yofel> BUGabundo: seb128_ did that already?
[22:27] <BUGabundo> ok
[22:27] <seb128_> BUGabundo, I did for the record, still need debugging from somebody on amd64
[22:28] <BUGabundo> seb128_: tells us what you ned
[22:28] <BUGabundo> *need
[22:28] <BUGabundo> I'm here to help :)
[22:28] <BUGabundo> ahahah
[22:28] <BUGabundo> and he left :\\\
[22:29] <cody-somerville> pitti, Whats holding up the gdm changes we agreed on?
[22:30] <cody-somerville> slangasek, ^^
[22:31] <cody-somerville> slangasek, We're quickly running out of time and the Xubuntu CDs are still oversized pending the changes to gdm
[22:31] <slangasek> cody-somerville: I'm not on the desktop team, I wouldn't know
[22:32] <slangasek> cody-somerville: is there a bug report open for this?
[22:32] <cody-somerville> slangasek, There was but it seems to be closed, trying to find it
[22:33]  * BUGabundo slaps seb128 connection
[22:33] <seb128> BUGabundo, what is required is somebody having access to an amd64 box and a clue about autotools and libtool to debug
[22:34] <BUGabundo> I have the 1st
[22:34] <BUGabundo> not the 2nd
[22:34] <BUGabundo> let me fetch someone from +1
[22:34] <giles> seb128: need debug info from somebody on amd64?
[22:34] <seb128> giles, not really, rather need somebody able to debug the issue
[22:35] <giles> which issue?
[22:35] <seb128> giles, ie giving me informations will not likely lead somewhere, I've no real clue about the issue seems to be something due to libtool
[22:35] <seb128> giles, cf bug #401938
[22:35] <seb128> "libtool: relink: gcc -shared .libs/io-png.o -lpng12 -L/build/buildd/gtk+2.0-2.17.5/debian/install/shared/usr/lib -L/usr/lib -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lm -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libpixbufloader-png.so -o .libs/libpixbufloader-png.so
[22:35] <seb128> /usr/bin/ld: cannot find -lgdk_pixbuf-2.0
[22:35] <seb128> collect2: ld returned 1 exit status"
[22:35] <cody-somerville> slangasek, LP #396321, LP#400901, LP #400094
[22:36] <cody-somerville> slangasek, I'm going to create a new master bug report to include all the details.
[22:37] <slangasek> cody-somerville: isn't bug #400901 that?
[22:37] <seb128> anybody on karmic amd64 who could give a build try to gtk+2.0?
[22:38] <seb128> to see if the build issue mentioned before and breaking png loading is a random glitch or a real error?
[22:38] <cody-somerville> slangasek, I'm going to modify 400901
[22:38] <giles> seb128: i could
[22:38] <seb128> giles, thanks
[22:39] <yofel> seb128: I'm building it too
[22:40] <seb128> thanks
[22:40]  * BUGabundo is looking :)
[22:46] <cody-somerville> slangasek, updated and milestoned
[22:50] <pitti> cody-somerville: ah, did you update your branch and merge request? didn't get a mail about it
[22:50] <seb128> pitti, hey
[22:50] <pitti> hey all
[22:51] <seb128> pitti, I expect bug #401938 to quickly become an issue
[22:51] <BUGabundo> hey pitti
[22:51]  * BUGabundo is always finding HIGH bugs for seb128 :)
[22:51] <seb128> pitti, just to let you know if you look at milestoned issues this week
[22:51] <pitti> seb128: oh, thanks; indeed, I'm the alpha-3 RM this week, so I have to care :)
[22:51] <cody-somerville> pitti, Sorry, I thought you were just going to make the changes. I'd be happy to update my branch for you.
[22:51] <seb128> BUGabundo, you seem to enjoy when users are in trouble
[22:52] <pitti> cody-somerville: I don't really know the appropriate xubuntu alternatives, and you said it also needs some patches for not hardcoding metacity, etc.?
[22:52] <cody-somerville> pitti, Sounds good to me. I'll do that this evening.
[22:52] <pitti> seb128: hm, I'm on amd64, and my icons are just fine
[22:52] <pitti> didn't update to new gtk yet, though
[22:53] <pitti> the most annoying thing is gnome-keyring ssh being broken (not exporting the env var)
[22:53] <seb128> pitti, well it's clear from the build log that the png loader didn't build on amd64
[22:53] <pitti> but just like so many of those, I guess it's a gdm bug again :/
[22:53] <seb128> pitti, didn't notice that there and gnome-keyring didn't change for some weeks
[22:54] <BUGabundo> seb128: no pleasure here. but I'm an alpha tester, so I've been finding many bugs over the years, helping to put them on BTSs, triaging, alerting users... the usual
[22:54] <pitti> seb128: yeah, SSH_AUTH_SOCK=/tmp/keyring-tYQTmS/socket.ssh ssh ... works
[22:54] <pitti> seb128: bit too late right now, but I'll give a go at that amd64 thing tomorrow morning
[22:54] <seb128> pitti, the environment export is a dbus thing I think
[22:54]  * pitti dist-upgrade
[22:54] <seb128> pitti, thanks, it's not the end of the world it's only icons
[22:55] <pitti> ah, there comes a new gtk
[22:55] <seb128> pitti, I just hate autotools and I've no amd64 box to look at what's going on
[22:55] <seb128> pitti, and I don't know enough about libtool to guess what is wrong without logs and access to a build
[22:55] <seb128> could be a race and work on next build, dunno
[22:56] <slangasek> directhex: monodevelop-boo appears to be in need of a fakesync, due to mismatched .orig.tar.gz md5sum
[22:57] <directhex> slangasek, is it? i believe the fakesync part, but i don't remember doing anything to break it recently
[22:59] <BUGabundo> ok my work here is done. thanks
[22:59]  * pitti cd /bed, good night
[22:59] <BUGabundo> bye pitti
[23:03] <yofel> seb128: the png loader built fine when just running ./configure && make - debuild and pbuilder are still running
[23:04] <seb128> yofel, ok thanks
[23:09] <directhex> of course, i apparently broke sid, so what do _I_ know?
[23:10] <directhex> oh, there's the problem, monodevelop-boo is missing from our tracker
[23:10] <directhex> wgrant, poke poke
[23:11] <directhex> mmm, still hasn't had a new upload since april
[23:12] <directhex> slangasek, was your comment simply regarding the funny version number? if so, a fakesync is fine, but i'm not sure what it would achieve given the packages are identical anyway
[23:14] <wgrant> directhex: Hi.
[23:14] <slangasek> directhex: no, the packages aren't identical, there's a build-dep on libgtksourceview2.0-cil
[23:15] <directhex> wgrant, can you manually add packages to an MDT page?
[23:15] <wgrant> directhex: I can.
[23:15] <directhex> slangasek, really? how silly
[23:15] <wgrant> directhex: But let's see if there's a more general way to get that one too...
[23:16] <directhex> wgrant, well, most of monodevelop* is with meebey as sole maintainer, not group maintained (according to control, anyway - not in reality)
[23:16] <wgrant> directhex: So, we only grab packages with one of the three mono maintainers right now.
[23:16] <directhex> slangasek, so a fakesync to universe just involves uploading a signed source package using our orig and their diff, yes?
[23:17] <wgrant> I guess I'll just add this explicitly now.
[23:17] <directhex> wgrant, sorry!
[23:17] <slangasek> directhex: yes
[23:17] <directhex> slangasek, okay, give me a minute. my first direct archive upload. eeks!
[23:19] <wgrant> directhex: It be there now.
[23:20] <directhex> tee hee, that makes things slightly more convenient:  -- Jo Shields<EMAIL_ADDRESS>Wed, 08 Apr 2009 22:42:33 +0100
[23:20] <directhex> wgrant, coolness. ta!
[23:22] <directhex> ehm... i take it i need to manually specify an upload distro in dput.cf? it's not bright enough to deal with "unstable -> karmic"?
[23:23] <Laney> it comes set up with ubuntu as default I think
[23:23] <Laney> (you should change this)
[23:23] <Laney> you do need to change the release in the changelog though
[23:24] <wgrant> Isn't one meant to add an XbuildY changelog entry for a fakesync?
[23:25] <seb128> wgrant, not if the tarball is different
[23:25] <seb128> wgrant, otherwise it will be tried by the auto-syncer and break
[23:25] <yofel> seb128: the debuild and pbuilder builds built without error too
[23:25] <directhex> Laney, you change the release in changelog for a fakesync?
[23:25] <seb128> yofel, and the png loader is built?
[23:26] <wgrant> seb128: But it is meant to be autosynced.
[23:26] <yofel> seb128: according to 'dpkg -L libgtk2.0-0' yes
[23:26] <seb128> wgrant, well, if the orig.tar.gz is different that's not going to happen
[23:26] <wgrant> seb128: It will when Debian uploads a new upstream.
[23:27] <wgrant> And until then the autosyncer will just not do anything.
[23:27] <seb128> wgrant, right, but we have no way to say to the auto-synced "it's a buildn version but try only next upstream version and not next revision"
[23:27] <Laney> directhex: yes sir, otherwise it will be rejected afaik
[23:27] <seb128> wgrant, it will break at each run until you sort it
[23:27] <wgrant> seb128: I see.
[23:27] <seb128> wgrant, 0.8-1build1 will try to autosync 0.8-2
[23:27] <wgrant> directhex: Soyuz works out the upload series by looking in the .changes, which is generated from the changelog.
[23:28] <directhex> Laney, can you suggest a fakesync changelog to read, to make myself feel better?
[23:28] <seb128> wgrant, and that will break the sync run on a md5sum mistmatch error
[23:28] <seb128> directhex, http://people.canonical.com/~pitti/scripts/syncpackage
[23:28] <Laney> directhex: I might have done one for one of the debuggers
[23:29] <seb128> directhex, in fact that's to do a real sync yourself so ignore it
[23:29] <Laney> but, just change the release to karmic
[23:29] <Laney> 0ubuntu1 the version number
[23:29] <seb128> directhex, basically get debian source, edit changelog to change unstable to karmic, build, sign, upload
[23:29] <directhex> Laney, that's a 0ubuntu1, not a fakesync, no?
[23:29] <wgrant> seb128: I see a lot of build1 fakesyncs
[23:30] <Laney> seb128: I thought that was what was just being discussed
[23:30] <seb128> wgrant, right, when the orig.tar.gz doesn't mismatch so next sync will work
[23:30] <Laney> erm
[23:30] <Laney> directhex: *
[23:30] <seb128> wgrant, that's what we do for rebuilds since we don't have bin-nmu
[23:30] <wgrant> seb128: No, these are for mismatched orig.tar.gzs.
[23:30] <seb128> wgrant, ie a package is in sync and need a rebuild you use build1 so next sync get it
[23:30] <wgrant> No.
[23:30] <directhex> seb128, good, binNMU is the work of the devil
[23:30] <Laney> I would 0ubuntu1 it to avoid it being autosynced
[23:30] <seb128> wgrant, well that's wrong and that will create issue during the next autosync run
[23:31] <seb128> wgrant, give me names ;-)
[23:31] <wgrant> seb128: A few of these were by archive admins...
[23:31] <wgrant> So I somehow think they are doing it the right way.
[23:31] <seb128> wgrant, can you give me an example?
[23:31] <wgrant> https://lists.ubuntu.com/archives/karmic-changes/2009-June/002294.html
[23:31] <directhex> Laney, not an issue, since the package  won't need to be changed until the next upstream release
[23:31] <directhex> *cough*
[23:31]  * Laney blinks
[23:31] <seb128> wgrant, archive admin have access to the autosync filters so they can put things on the ignore list if they want
[23:32] <directhex> meh, close enough for government work. where'd i put that dput...
[23:32] <seb128> but I think it's easy using an ubuntu<n> versioning
[23:32] <seb128> wgrant, I will check with pitti tomorrow
[23:33] <cjwatson> I think build1 plus a blacklist entry is fine
[23:33] <seb128> he probably added the source to the don't sync list
[23:33] <seb128> cjwatson, well it's extra archive admin work compared to using 0ubuntu1 and asking for a sync later
[23:33] <cjwatson> I'm not sure it actually is extra work; manual syncs are work too
[23:33] <cjwatson> and about the same amount, tiny either way
[23:34] <seb128> that's maybe because I don't check for packages on the list often
[23:34] <cjwatson> anyway, /me -> sleep -> debconf
[23:34] <seb128> ie if I'm doing sync those are likely to stay on the "do not sync" list for a while
[23:34] <seb128> ie, it's not trivial to know when to drop them from the list
[23:36] <seb128> yofel, ok thanks, I've a uploaded a no change rebuild version
[23:36] <seb128> let's see how it works
[23:37] <yofel> seb128: after installing my self-build .deb files everythings ok again
[23:38] <seb128> yofel, ok, good, I've no explanation about the issue
[23:39] <dupondje> i'm trying to compile it here also, checking if it works also
[23:39] <seb128> I've uploaded a new revision
[23:39] <seb128> it will have built in 16 minutes or so
[23:39] <seb128> let's see how that one goes
[23:39] <dupondje> good thing :)
[23:43] <NoelJB> seb128: I understand that you just posted the fix.  Thank you for the very prompt response.  :-)  [sometimes a "thank you" is the only currency in Open Source]
[23:44] <dupondje> its not a real fix tho, its just a reupload to rebuild it
[23:44] <seb128> NoelJB, thanks, dunno if that build will work, I don't know why the previous one had the issue
[23:53] <seb128> ok, new gtk built correctly now and fixes the issue
[23:54] <yofel> seb128: thanks :)
[23:55] <seb128> yofel, thank you for testing and reporting the issue early


[00:38] <Logan_> infinity: mind a quick PM?
[00:40] <infinity> Logan_: Go nuts.
[08:13] <Laney> @pilot in
[08:13] <Laney> xnox: is that lies?
[10:48] <xnox> @pilot out
[10:48] <xnox> yes lies
[10:49] <Laney> lies begone
[13:07] <Laney> @pilot out
[13:21] <Laney> smoser: do you know why http://cloud-images.ubuntu.com/utopic/ doesn't have a current/ symlink?
[13:22] <smoser> Laney, raised yesterday by pitti.
[13:22] <Laney> I guess for the same reason ;-)
[13:22] <smoser> http://irclogs.ubuntu.com/2014/04/30/%23ubuntu-devel.html#t05:56
[13:24] <Laney> smoser: I see your reply, okay ...
[13:43] <mpt> cyphermox, what’s the maximum length for a Wi-Fi access point name?
[13:45] <xnox> mpt: 32
[13:45] <Laney> bytes
[13:46] <mpt> thanks
[13:48] <mpt> …Which may include emoji. http://f.cl.ly/items/1H2s3G1B3Q1l1C35452I/network.png
[13:51] <mlankhorst> ;D
[13:51] <xnox> mpt: correct, the spec didn't actually specify what encoding it's suppose to be.
[13:52] <mlankhorst> utf-8 of course!
[13:58] <xnox> mlankhorst: KOI8-R ftw!
[14:09] <mlankhorst> no!
[14:09] <xnox> mlankhorst: honestly you'd get kicked from russian irc channel for speaking in utf-8
[14:10] <mdeslaur> xnox: oh? do you use two irc clients or something?
[14:11] <mlankhorst> last time i was on a russian server (iirc) it offered an option to set utf-8 and it would do the translating for you :P
[14:11] <xnox> mdeslaur: no, i've emigrated
[14:11] <xnox> =)
[14:11] <mdeslaur> heh
[14:12] <mlankhorst> well, translation between character sets
[14:12] <mdeslaur> ah, interesting
[14:37] <bdmurray> arges: could you have a look at update-manager in the saucy proposed queue?
[14:37] <arges> bdmurray: sure
[14:39] <stgraber> hallyn: so did you talk to pitti about your systemd-logind weirdness in utopic?
[14:42] <arges> bdmurray: (making a mental note for myself) update-manager updates have version changes like that?
[14:42] <hallyn> stgraber: no, not yet.
[14:42] <arges> bdmurray: since its ubuntu only right
[14:42] <bdmurray> arges: right
[14:44] <arges> bdmurray: is this fixed in all other versions then? or doesn't affect others
[14:46] <bdmurray> arges: looking at the errors bucket it still only affects saucy
[14:47] <hallyn> pitti: (punting on the systemd-logind weirdness first,) do you think converting /etc/init/{cgmanager,cgproxy}.conf to systemd units would be hard?  Is there guidance yet about how to properly do such a conversion?
[14:48] <arges> bdmurray: ok accepted
[16:11] <hallyn> say, is anyone looking into updating util-linux?  (i.e will i be wasting my time if i start to)
[16:11] <cjwatson> hallyn: infinity is
[16:14] <hallyn> cool
[16:17] <dunkel2> hello
[17:20] <slangasek> pitti: I'm very confused by this doodle poll; I thought doodle had an option to show times in your local timezone, and it's not giving me that option at all... and if these are London times, it doesn't make sense to me why the options are the ones that they are
[17:20] <slangasek> pitti: so before I fill out the poll, I want to make sure 5am-8am,3pm-10pm Europe/London are the right options...
[17:42] <arges> Quick Start
[17:42] <arges> whoops
[17:44] <Logan_> cjwatson: could you please add me to ~ubuntu-transition-trackers?
[17:45] <xnox> Logan_: what transition do you want to setup? pastebin the config and/or do merge proposal and i'll commit it.
[17:45] <Logan_> but I want the power ;P
[17:45] <Logan_> sure, I'll do an MP, but I'd like to be part of the team
[17:46] <Laney> Show that you can construct correct files a couple of times, then you can be added
[17:46] <Logan_> sure
[17:50] <Logan_> xnox, Laney: did an MP
[17:57] <xnox> Logan_: with $ reverse-depends libmpich10 --list | xargs bin2src | sort -u | wc
[17:57] <xnox> Laney: i get 24 affected packages, yet when i run that config above, i only get 7 affected packages?!
[17:57] <xnox> i'll update my packages file
[17:58] <Logan_> that's odd
[17:59] <Logan_> xnox: it appears that the config is only returning the ones without architectures listed
[17:59] <Logan_> how do we account for the ones with architectures listed?
[17:59] <Laney> check affected, not good or bad
[18:00] <Logan_> ah, so it won't say that ones with architectures listed are bad, even if they are depending on the older version of the library?
[18:03] <Laney> It's true that liboasis3-0d only depends on libmpich10 on arm64 and doesn't build-depend on it, to take an example
[18:53] <Logan_> Laney: I have no idea why that would be the case... shouldn't there be an explicit build dependency, then?
[18:55] <Logan_> Laney: should the .ben file just say that it affects ones that currently depend on libmpich10?
[18:56] <Logan_> (instead of looking at the build dependencies?)
[19:07] <Logan_> Laney: submitted a new MP just looking at Depends rather than Build-Depends
[19:19] <hallyn> can anyone tell me what is wrong with teh following:
[19:19] <hallyn> AC_SEARCH_LIBS([cgmanager_get_pid_cgroup_abs_sync], [cgmanager], [have_abs_cgroups=yes], [have_abs_cgroups=no], [nih nih-dbus dbus-1])
[19:19] <hallyn> configure is not adding the listed libraries when trying to build the test program...
[19:19] <hallyn> i.e. no -lcgmanager
[19:24] <hallyn> ah maybe i just had it in a place it didn't like
[19:29] <hallyn> phew, yeah now it's all right
[20:31] <bdmurray> mlankhorst: why did the xmir patch change in the xserver-xorg-video-ati upload in the trusty -proposed queue?
[20:46] <Sarvatt> bdmurray: fix-0-crtc-crash.patch was touching the code xmir.patch touched and it needed updating
[20:52] <Sarvatt> its just whitespace changes
[20:53] <bdmurray> Sarvatt: I see, okay thanks!
[21:02] <bdmurray> hallyn: is there an upstream samba bug for bug 1310919?
[21:05] <hallyn> bdmurray: https://bugzilla.samba.org/show_bug.cgi?id=10490
[21:08] <bdmurray> hallyn: do you think we should wait and see what upstream does?
[21:09] <hallyn> bdmurray: tough call.  it's prevent logins...  that's pretty critical.
[21:09] <hallyn> otoh it'll suck to have to sru a patch replacement if upstream does it differently
[22:00] <bdmurray> Laney: it looks like you referenced the wrong bug in your upload of apport to the precise -proposed queue. Bug 1007826 vs bug 1015788.
[22:07] <Laney> bdmurray: I don't think so, the second one is another go at fixing the first one, isn't it?
[22:08] <Laney> I certainly tried to take both of those commits, hopefully successfully
[22:11] <bdmurray> Laney: the diff contains no change to apport-cli
[22:12] <Laney> why should it?
[22:13] <Laney> The fixes were to launchpad.py
[22:13] <bdmurray> The quantal changelog refers to "
[22:14] <bdmurray> apport-cli: Unbreak "keep" option. (LP: #1007826)
[22:14] <bdmurray> see https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/apport/quantal/revision/321
[22:14] <bdmurray> and the change to apport-cli there
[22:14] <Laney> Give me a second and I'll get the commits
[22:22] <Laney> bdmurray: Hmm, I'm less sure that I took the right commit now
[22:23] <Laney> Those are the ones I meant to take but a second look makes me think that they don't fix the reporter's problem
[22:23] <Laney> Leave or reject it and I'll look again tomorrow or next week
[22:24] <tsutsifr> Is there something I can target a debootstrap against that's smaller than ubuntu-minimal? I'm trying to create a tiny docker base-image, which still needs to be able to use apt-get -- but which (since it's a docker container) doesn't need to do things like boot, configure devices, or start a shell
[22:26] <Laney> bdmurray: (if you can identify the correct commit then please do and upload that instead)
[22:26] <Laney> (or as well as)
[22:26]  * Laney goes away, goodnight
[22:26] <tsutsifr> my current approach is creating a "ubuntu-minimal-docker" virtual package that Provides ubuntu-minimal, along with the transitive closure of packages it depends on, minus the actually-necessary ones, like apt and debconf
[22:37] <cjwatson> tsutsifr: --variant=minbase
[22:37] <cjwatson> (=> Priority: required + apt)
[22:57] <tsutsifr> cjwatson: that gives me ubuntu's equivalent to debian's minbase, yes, but when I actually go to install anything packages for ubuntu, ubuntu-minimal and its various dependencies will end up being Depended on anyway, so doing that is kind of moot
[22:57] <tsutsifr> *anything packaged for ubuntu
[23:00] <mwhudson> hm, dist-upgrade in a chroot is complaining at me
[23:00] <mwhudson> invoke-rc.d: initscript systemd-logind, action "start" failed.
[23:01] <mwhudson> this looks like the sort of thing i don't care about in a chroot
[23:03] <tsutsifr> and even then, it looks like minbase pulls in most of the same unnecessary stuff (initramfs, e2fs*, kmod, plymouth, sysvinit, udev, upstart...)
[23:06] <sarnold> mwhudson: that's working as intended -- invoke-rc.d 'knows' some things in a chroot environment or container environment shouldn't be executed, the invoke-rc.d manpage has details
[23:06] <mwhudson> sarnold: leaving packages unconfigured surely isn't intended though
[23:07] <mwhudson> libpam-systemd:arm64 in this case
[23:07] <mwhudson> is that just a packaging bug?
[23:07] <tsutsifr> basically, it seems like there should really be a differentiation in Essential packages, between "Essential even when the OS is being effectively used as an exokernel by a single process" and "Essential only for autonomous system functioning"
[23:07] <sarnold> mwhudson: hrm, indeed, they shouldn't be unconfigured afterwards, just not running..
[23:07] <tsutsifr> and things that currently depend on ubuntu-minimal should probably depend on a virtual package that provides the former, not the latter
[23:22] <mwhudson> can i pretend to dpkg that this package is in fact configured?
[23:22] <mwhudson> i guess i can symlink it's postinst to true
[23:23] <mwhudson> -'
[23:34] <infinity> mwhudson: chroots should have a policy-rc.d in place that denies invoke-rc.d entirely, so you don't run into failed starts.
[23:34] <mwhudson> infinity: oh right
[23:34] <infinity> mwhudson: That's hardly the only package you'll have a problem with.
[23:34] <mwhudson> oh right, i didn't actually make this chroot with schroot


[20:18] <zoose> hello, wots occurrin'
[20:19] <zoose> it's been a mighty long time since i've been in here.
[20:30] <zoose> i just found about "freegeek" and i looked online and seen a central florida freegeek but the dates on the ubuntu forums were from 2007. does anyone know if this is still around?
[20:51] <zoose> i just did more looking and seen this. https://en.wikipedia.org/wiki/Free_Geek  no centralFL. :(


[00:26] <VMGuy23> guys im going to unplug a usb drive without ckuckdigi eject
[00:26] <VMGuy23> *clicking
[00:31] <sarnold> rip your filesystem consistency
[00:31] <VMGuy23> theres nithing on that 256mb usb
[00:31] <VMGuy23> nothinh
[00:32] <VMGuy23> nothinmh
[00:32] <VMGuy23> nothnh
[00:32] <VMGuy23> nothing
[00:40] <tomreyn> i believe you are trying to depict the new state of data on this usb drive
[00:40] <VMGuy23> there was never anyrging n it
[00:40] <VMGuy23> *anything on
[00:40] <tomreyn> we two certainly have the same fat fingers
[00:41]  * VMGuy23 Automatic Hand Spellcheck exited with code 1
[00:42] <tomreyn> at least it didnt segfault
[00:42] <VMGuy23> Log: line 273: "Segmentation fault (core dumped)"
[02:05] <tomreyn> VMGuy23: so, are you using the new irc lcient, yet?
[02:05] <tomreyn> *client
[02:05] <VMGuy23> hexchat
[02:05] <tomreyn> and that's more stable?
[02:06] <VMGuy23> Srain is too buggy and i dont know of any other good ones
[02:06] <VMGuy23> Srain caused a 240 minute ban due to reconnect cycles
[02:06] <tomreyn> i see, so the reconnects you did after switching are voluntarily?
[02:07] <tomreyn> it's most likely less now then
[02:07] <VMGuy23> I did some reconnects recently as i failed to reset the leave and join messages
[02:07] <tomreyn> but if you're in a place with bad internet or moving much you might consider a bouncer
[02:07] <VMGuy23> also im in the middle of learning how i3 works
[02:08] <VMGuy23> tomreyn: my internet is great
[02:08] <VMGuy23> it was the client that caused the loops
[02:08] <tomreyn> znc works well for me
[02:08] <VMGuy23> i have a freebnc or something account
[02:08] <tomreyn> you just need a properly connected server
[02:09] <tomreyn> that would also work but then you have no control on who else is reading
[02:09] <tomreyn> but then, this is mostly public chat anyways
[02:10] <VMGuy23> my internet is good, the laptop i use isnt. Intel Atom. Also doesnt help the wifi chip in this isnt 802.11ac
[02:13] <tomreyn> oh, atom :-/
[02:13] <tomreyn> well i have one, too, and it actually works fine
[02:13] <sarnold> clean the fans? check heatsinks to make sure they're still affixed to the cpu?
[02:14] <tomreyn> VMGuy23: does it power off by itself then?
[02:15] <VMGuy23> tomreyn: no. The reason why i keep disconnecting is because i'm maybe resetting a hexchat thing or restarting my i3 session
[02:15] <tomreyn> ok, that's what i thought
[05:50] <marcoagpinto> Hello!
[18:12] <tomreyn> TJ-: they're well aware, don't waste your energy on FreeBDSM
[18:13] <TJ-> oh, is this another 'Hash' ?
[18:13] <ravage> he has been trolling since he joined really
[18:13] <tomreyn> i've had similar conversations with him
[18:14] <tomreyn> or 'them', but probably 'him'
[18:18] <TJ-> yeah, looking at my logs, goes back to 2018