[14:12] <kanliot> yawn
[15:02]  * stgraber waves
[15:02] <infinity> o/
[15:02]  * xnox high-5
[15:02] <ev> hi
[15:03]  * slangasek waves
[15:03]  * ogra_ shores
[15:03] <slangasek> #startmeeting
[15:03] <meetingology`> Meeting started Wed May  2 15:03:37 2012 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:03] <meetingology`> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:04] <slangasek> [TOPIC] Lightning round
[15:04] <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra infinity cjwatson xnox)
[15:04] <slangasek> doko stgraber cjwatson slangasek barry xnox jodh ogra ev infinity bdmurray
[15:05] <slangasek> $
[15:05] <ogra_> €
[15:05] <slangasek> £
[15:05] <slangasek> doko: you first :)
[15:06] <doko> - gcc updates for quantal
[15:06] <doko> - investigate and fix arm biarch builds
[15:06] <doko> - may 1st was bank holiday
[15:06] <doko> (done)
[15:06] <stgraber> Was off Friday and Tuesday:
[15:06] <stgraber> - Blueprints
[15:06] <stgraber>  - Registered community-q-edubuntu, foundations-q-ltsp, foundations-q-iso-tracker and foundations-q-networking
[15:06] <stgraber> - Installer
[15:06] <stgraber>  - Merged some dconf improvements and turned on compositing in the installer.
[15:06] <stgraber>  - Fixed some netboot bugs and turned on cifs support in casper.
[15:06] <stgraber>  - Merged os-prober from Debian
[15:06] <stgraber> - Release
[15:06] <stgraber>  - ISO testing
[15:06] <stgraber>  - Ubuntu/Edubuntu 12.04 release.
[15:06] <stgraber> - TODO this week
[15:06] <stgraber>  - Look for any missing blueprint and register them
[15:06] <stgraber>  - Continue with merges (currently working on ifupdown)
[15:06] <stgraber>  - Push some SRUs (nagios-nrpe and ldm are currently on my list)
[15:07] <stgraber> (DONE)
[15:07] <cjwatson> Release sprint.  Nothing went too badly wrong. :-)
[15:07] <cjwatson> Opened quantal and got auto-syncs running.  Some degree of fighting with Launchpad, but less than usual.  Piles of merges.
[15:07] <cjwatson> Removed the data.tar.xz dpkg Pre-Depends requirement from Launchpad.
[15:07] <cjwatson> Sorted out a few specs.
[15:07] <cjwatson> Got a bit carried away with update-manager and ubiquity Python 3 porting.  Lots of dependencies still, and I haven't got much into bytes/unicode data modelling, but making good progress on tests.
[15:07] <cjwatson> .
[15:08] <slangasek>  * upstart in Debian:
[15:08] <slangasek>   * prereq patches for lsb, sysvinit, and debhelper are done or pending
[15:08] <slangasek>   * hacking on invoke-rc.d to implement the Debian policy proposal (doing what /lib/init/upstart-job does currently)
[15:08]  * infinity nudges Mr Manager.
[15:08] <slangasek>   * plymouth patches wanted for mountall, looking at it this week
[15:08] <slangasek>  * SRUs for multiarch libraries, hdparm, other things
[15:08] <slangasek>  * fix upgrade issue in libnfsidmap (bug #933870)
[15:08] <slangasek>  * don't restart kdm on eglibc upgrade (bug #985735)
[15:08] <slangasek>  * help fix upgrade issues with python (bug #986374)
[15:08] <slangasek>  * sponsor upstart fixes from James
[15:08] <slangasek>  * merges merges merges
[15:08] <slangasek>  * python3 porting: bluez ported (thanks Laney for the upload), gdb breaking my brain
[15:08] <slangasek>  * UDS planning - get those blueprints in, everybody!
[15:09] <barry> slangasek, cjwatson: \o/
[15:10]  * barry assumes slangasek is done...
[15:10] <barry> (reporting for last two weeks)  py3 porting status: debian bug 669301 (py3 packaging for python-openssl, should probably temporarily delta this into quantal).  freedesktop bug 48904 (backward compat problem w/ dbus.gobject_service).  worked on packaging for python-mode.el for sid.  released flufl.* packages with updated cheeseshop py3 trove classifiers.  also spent some time on bug 924079 before release, but punted.  reviewed debian bug
[15:10] <barry> 625509 (debian-python port).  reviewed slangasek's patch for bluez py3.  bug 990145 (remove gwibber dependency on mx.DateTime).  bug 992195 (remove duplicity dependency on GnuPGInterface).  TODO: will be sprinting w/local pythonistas tomorrow on pep 420 (namespace packages for py3.3) and continue with bug 992195.  done.
[15:10] <slangasek> er yes, sorry
[15:11] <xnox>  did hr/new employee procedure tasks, some are still pending
[15:11] <xnox> - finished testing lvm2 merge, it got updated in debian,
[15:11] <xnox>   remerged, needs further retest
[15:11] <xnox> - did one sync request (libgpg-error)
[15:11] <xnox> - finishing up merging sudo, should be ready for sponsorship later
[15:11] <xnox> - created uds spec, wrt failing hardware notifications
[15:11] <xnox> - just did a merge proposal for boost1.49 transition tracker
[15:11] <xnox> NEXT
[15:12] <infinity> jodh: You're up, since you were disconnected for the randomizer. ;)
[15:12] <slangasek> xnox: I'd like to upload lvm2 .88 now and worry about .95 later, especially since .88 is the most recent version that I know upstream recommends
[15:12] <xnox> slangasek: ok.
[15:12] <slangasek> xnox: but I'll test it on my own system first before doing so
[15:13] <slangasek> either way, good to have one of our top packages knocked off of http://qa.ubuntuwire.org/oldmerges/ :)
[15:13]  * ogra_ wonders if there is actually a human being behind the jodh nick :)
[15:13]  * ogra_ just moves forward for now
[15:14] <ogra_> done:
[15:14] <ogra_> * more compiz upgrades right before/on release
[15:14] <ogra_> * omap, omap4 and ac100 release image tests
[15:14] <ogra_> * may 1st was labour day in germany ...
[15:14] <ogra_> * packaged the new nvidia tegra armhf driver (sadly very buggy on the ac100 atm (suspiciously looks like the GPU hardlocks
[15:14] <ogra_>   after a while, nvidia devs are notified)) (the test package can be found at http://people.canonical.com/~ogra/nvidia-tegra/ atm)
[15:14] <ogra_> todo:
[15:14] <ogra_> * merges: i only have procps on the list, feel free to drop stuff on me, else i'll randomly grab bits off the list
[15:14] <ogra_> * pondering if we shouldnt have a spec for MBR and partition table backup/restore
[15:14] <ogra_>   (i know that came up various times in the past but i couldnt find a spec for it)
[15:14] <ogra_> UDS:
[15:14] <ogra_> registered https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-embedded-rootfs
[15:14] <ogra_> registered https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-hwpack-integration
[15:14] <ogra_> (done)
[15:15] <slangasek> ev:
[15:15] <ev> - http://errors.ubuntu.com is live, though due to a programming error, things
[15:16] <ev>   went down over the weekend. Fortunately, the system is designed to cope with
[15:16] <ev>   this and clients resent crashes when it came back up on Monday. We're still
[15:16] <ev>   getting things hooked into the webops pager system.
[15:16] <ev> - Fixed a few bugs that have arisen in the web side of the crash database
[15:16] <ev>   since release.
[15:16] <ev> - Fixed a critical bug in apport as version 2.0.1-0ubuntu7. We were directing
[15:16] <ev>   people to launchpad.net post-release.
[15:16] <ev> - We now have (the start of) a web API for the crash reporting statistics.
[15:16] <ev>   This was initially written to provide webops with a means on monitoring the
[15:16] <ev>   health of the retracers.
[15:16] <ev> - Created the 12.04 USB disks for the store.
[15:16] <ev> - As it turns out, 4 i386 and 4 amd64 retracer instances wasn't enough
[15:16] <ev>   post-release. Initial testing suggests we could get by with about 16 of
[15:16] <ev>   each. We'll also need a lot more disk space, as between the backlog of core
[15:16] <ev>   dumps and the per-retracer per-release caches we're quickly eating up the
[15:16] <ev>   existing disk. Worked with webops to rememedy the immediate problem. New
[15:16] <ev>   hardware is on order.
[15:16] <ev> - Registered blueprints for UDS:
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-crash-database
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-metrics
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-updates-from-crash-reports
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-ddebs
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-bucketing-improvements
[15:16] <ev>   - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-phased-updates
[15:16] <ev> - Worked with Matthew to try to write a better mean time between failures
[15:16] <ev>   algorithm. Mathematicians wanted.
[15:16] <ev> - Built out support to collect statistics on the release, package, version,
[15:16] <ev>   year, month, and day level (and combinations therein).
[15:16] <ev> - Started moving the web UI to consuming its own API to generate the charts,
[15:16] <ev>   in support of being able to switch chart views via fancy-pants AJAX.
[15:16] <ev> - Discussed the http://errors.ubuntu.com design with Matthew, Kate, and Colin.
[15:16] <ev>   If you get a chance, I'd love your thoughts in reply to the email I sent
[15:16] <ev>   about it on April 13th.
[15:16] <ev> (done)
[15:16] <ev> I'll post some fun stats during AOB
[15:16] <infinity> ev: When will errors.ubuntu.com be usable by !canonical people (or will it ever?)
[15:17] <infinity> - Release sprint last week:
[15:17] <infinity>   - 12.04 got released, rather uneventfully
[15:17] <infinity>   - 12.10 got opened while no one was looking
[15:17] <infinity> - This week:
[15:17] <infinity>   - Fixed d-shlibs to deal with the armhf linker
[15:17] <infinity>   - Fixed a few bugs in the fpc/armhf bootstrap
[15:17] <infinity>   - Worked on fixing some llvm/clang-on-arm issues
[15:17] <infinity>   - Rebootstrapped the tex* stack to sort out an
[15:17] <infinity>     accidental out-of-order sync that blew up the world
[15:17] <infinity>   - Registered and fiddled with spec for UDS.
[15:17] <infinity> ...
[15:17] <ev> infinity: well, I'm not shouting about it from the rooftops yet as the code could use some performance improvements
[15:17] <ev> and I really, really, really don't want Hacker News hitting it
[15:17] <ev> just yet
[15:18] <slangasek> ev: speaking of retracers, I noticed the backtraces shown in the errors reports don't appear to be a 'bt full' - is there any plan to make this available?
[15:18] <infinity> ev: Sure, but I mean it's currently behind SSO demanding that you're in the canonical group. :)
[15:18] <slangasek> it's relevant often enough that I think we should have it by default
[15:18] <ev> infinity: but the game plan is canonical group + bug control being able to access the actual reports
[15:18] <ev> just like on launchpad
[15:18]  * infinity nods.
[15:19] <Laney> use ubuntu-dev instead for now, or bugcontrol?
[15:19] <ev> slangasek: can you provide me with an example?
[15:19] <ev> it's definitely not intentional
[15:20] <slangasek> ev: looking
[15:20]  * bdmurray starts then
[15:20] <bdmurray> bug triage of ubiquity, iso-testing and update-manager bug reports
[15:20] <bdmurray> investigation into reporters submitting dist-upgrade bugs multiple times
[15:20] <bdmurray> closed apport-package reports regarding package install failures due to not a debian package
[15:20] <bdmurray> wrote a bugbot routine for 'not a debian format archive bug reports'
[15:21] <bdmurray> closed texinfo bug reports due to a syntax error in /etc/environment
[15:21] <bdmurray> whoopsie apport-package duplicate bug consolidation into bug 988995
[15:21] <bdmurray> tried to recreate bug 987956 regarding ubiquity
[15:21] <bdmurray> wrote a bug pattern for bug 937546
[15:21] <bdmurray> reported apport bug 989929 regarding checking if a package is an ubuntu package
[15:21] <bdmurray> conversion of harvest opportunities from direct launchpad database queries to using the api
[15:21] <bdmurray> blogged regarding duplicate bug title consolidation
[15:21] <bdmurray> created a list of people who improved bug reports during the precise dev cycle for skaet
[15:21] <bdmurray> investigation into remastersys and emailed contact person regarding bug 984276
[15:21] <bdmurray> created a launchpad development virtual machine
[15:21] <bdmurray> created a couple of blueprints for Q
[15:21] <bdmurray> done
[15:21] <slangasek> ev: "no symbol table info available", so maybe this was a missing debug symbol problem. https://errors.ubuntu.com/oops/008aa98e-92ea-11e1-b399-2c768aafd08c
[15:22] <doko> msg infinity did you give back gcc-4.7? these mysterious give backs become annoying ...
[15:22] <doko> oops
[15:22] <slangasek> bdmurray: texinfo> can you give us a bug about fixing texinfo to not muck around in /etc/environment where it doesn't belong?
[15:22] <infinity> doko: I did a mass-give-back of the world yesterday, nothing today...
[15:23] <infinity> doko: But that wouldn't have hit PPAs, if your PPA upload is what got given-back.
[15:23] <doko> right
[15:23] <bdmurray> slangasek: yes, will do
[15:23] <slangasek> ta
[15:24] <slangasek> jodh: your turn, if you're around :)
[15:24] <jodh> - boot/upstart: - Raised MP on quantal upstart to fix compile error.
[15:24] <jodh> - planning/blueprints:
[15:24] <jodh>   - discussions around multiseat.
[15:24] <jodh>   - service readiness:
[15:24] <jodh>     https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-service-readiness
[15:24] <jodh>   - ptrace limitations:
[15:24] <jodh>     https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations
[15:24] <jodh> - libs/nih: bug 776532 (required for Upstart quantal work). Wrote tests and
[15:24] <jodh>   tested. Approved by Keybuk.
[15:24] <jodh> - TODO:
[15:24] <jodh>   - ConsoleKit+logind investigations + multiseat blueprint with robert_ancell.
[15:24] <jodh>   - upstart job disabling blueprint.
[15:24] <jodh>   - upstart state passing blueprint.
[15:25] <jodh> ⨌
[15:25]  * slangasek feels all integrated
[15:26]  * infinity feels dirty
[15:26] <stgraber> jodh: can you make sure I'm subscribed to the multiseat blueprint? (I have an interest because of past experience with these and because of LTSP)
[15:27] <jodh> stgraber: will do.
[15:27] <slangasek> jodh: please also register a general "upstart roadmap" blueprint - we should have that session again just to make sure we're still aligned with what people need
[15:27] <cjwatson> I didn't even know there *was* a quadruple integral operator.
[15:27] <jodh> slangasek: ack.
[15:28] <stgraber> jodh: thanks
[15:28] <slangasek> anyone have questions over the above?
[15:30] <slangasek> [TOPIC] UDS blueprints
[15:31] <slangasek> so with UDS half a week away, any remaining blueprints you mean to have on the schedule need to get in the system ASAP
[15:31] <slangasek> tomorrow at the latest
[15:31] <cjwatson> I've got "btrfs sync-up with server team" and "automated bootloader testing" to do from our call yesterday
[15:31] <cjwatson> will register those today
[15:31] <slangasek> and by Friday at the latest, please have a look at what's on the schedule for UDS and get yourself subscribed to the sessions you need to be at
[15:31] <slangasek> so that the autoscheduler can do its work over the weekend
[15:32] <slangasek> instead of having it throw conflicts at us Monday :)
[15:32] <slangasek> cjwatson: thanks
[15:32] <infinity> (For the record, if people have sessions they think I should be at, feel free to subscribe me)
[15:33] <ogra_> infinity, do we have an arm v8 spec btw ?
[15:33] <infinity> Yep.
[15:33] <slangasek> I expect that as usual none of you should have any trouble finding things to occupy your time at UDS; but if anyone should happen to feel they don't have enough that they're participating in, let me know
[15:33] <ogra_> (assuming it would be yours if it exists)
[15:33] <infinity> ogra_: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-aarch64-porting
[15:33] <ogra_> thx
[15:34]  * ogra_ subscribes
[15:34] <infinity> Cleverly hidden under the arch name that no one knows.
[15:34] <ogra_> hehe
[15:34] <cjwatson> Anyone know if wookey's already planning to set up a quantal sbuild-ma buildd in time for UDS?
[15:34] <slangasek> ev, bdmurray: incidentally, do you think one session about the crashdb is sufficient? (https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-crash-database)
[15:34] <cjwatson> I'd ask him directly but he's not on IRC right now
[15:35] <slangasek> he's on #multiarch@OFTC :)
[15:35] <slangasek> (I don't know)
[15:35] <ev> slangasek: as in should we have foundations-q-crash-database-2?
[15:35] <infinity> I was just about to mention he was on oftc. :P
[15:35]  * ogra_ sees him in #linaro
[15:35] <ev> or are you asking if we should split it out into more specs?
[15:35] <slangasek> ev: as in, are there subtopics that warrant an hour of their own :)
[15:35] <cjwatson> ah, I'll ask him there
[15:36] <ev> slangasek: I'll give that a think tonight
[15:36] <ev> it does link to some subtopics
[15:36] <ev> but yeah, maybe the mean time between failures is an hour talk itself
[15:37] <slangasek> ev: if it's simpler we can just block out multiple hours for the umbrella blueprint
[15:37] <ev> yeah, lets do that
[15:37] <slangasek> though sometimes that just means the first topic takes two hours and you never get to the end of the list ;)
[15:37] <ev> heh
[15:37] <ev> I'll still think about how we can further break this down tonight
[15:38] <ev> but lets tentatively plan for two hours
[15:38] <slangasek> any other concerns about blueprints at the moment?
[15:38] <ogra_> any suggestions about hving a blueprint for a partition table and MBR backup restore ?
[15:38] <ogra_> *having
[15:38] <ogra_> (mentioned in my report above)
[15:39] <slangasek> ogra_: I wasn't sure I understood the use case for this
[15:39] <ogra_> having backups of your partition table in case you falsely change it ?
[15:39] <slangasek> who does that though? :)
[15:39] <ogra_> being able to restore a messed up MBR a user fiddled to death
[15:40] <ogra_> dunno, i kno win the past having grub do backups on grub-update came up
[15:40] <cjwatson> update-grub doesn't touch the partition table or the MBR
[15:40] <ogra_> (and we had such discussions for u-boot as well)
[15:40] <cjwatson> You may be thinking of grub-install
[15:40] <ogra_> oh, indeed, wrong term, sorry
[15:41] <slangasek> right, and grub-install doesn't get run except at install time
[15:41] <cjwatson> I dunno, it seems like a special case of having good system backups
[15:41] <ogra_> k, so its moot
[15:41]  * xnox .oO(UEFI)
[15:41] <slangasek> ogra_: I suspect we can't justify a session for it - but thanks for bringing it up
[15:41] <ogra_> right, might make more sense in context of an advanced backup tool
[15:41] <cjwatson> ... which we still don't do well
[15:42] <slangasek> do we want system backups on the agenda?
[15:42] <slangasek> or would that need to be desktop / server instead of foundations?
[15:42] <ev> don't we have deja dup?
[15:42] <ev> it sometimes manages to back up to u1
[15:42] <cjwatson> ev: Have you ever tried to do system restores based on duplicity backups?
[15:42] <cjwatson> I have.  It doesn't work.
[15:42] <ev> cjwatson: yikes
[15:42] <ogra_> heh ... sometimes
[15:43] <cjwatson> (Among its faults, it stores file ownership by user/group name rather than number, so you can't reliably restore from a live CD without having to spend ages fiddling with permissions afterwards.  It's obviously meant as a single-user backup tool, not a system backup tool.)
[15:44] <cjwatson> slangasek: I suspect nobody has time for it this cycle :-)
[15:44] <slangasek> right-o
[15:44] <slangasek> moving on then
[15:44] <slangasek> [TOPIC] Bugs
[15:44] <cjwatson> Maybe I should talk to mterry and see if duplicity can be bludgeoned into the right shape, since it's clearly desktop's direction
[15:44] <ev> cjwatson: noted - my experience with it has been fairly light
[15:44]  * xnox bacula - is ok for system backups
[15:44] <slangasek> bdmurray: are there any bugs showing up post-release that we should be worrying about SRUing?
[15:44] <barry> duplicity is one of those py3 application ports, so there's even more to bludgeon mterry with :)
[15:45] <slangasek> (ones that we aren't already)
[15:45]  * stgraber uses a central backuppc server with rsync for all the Linux systems, works great but not exactly something we can fit in the default install
[15:45] <bdmurray> slangasek: well, I ran across bug 988995 which reminded me of another bug
[15:46] <bdmurray> bug 523896
[15:47] <cjwatson> stgraber: Right, roughly me too, but it's all home-grown
[15:47] <ev> yeah, I did ask about that in #ubuntu-devel
[15:47] <ev> I'm not sure what else we can do if /etc/passwd is locked
[15:47] <slangasek> 523896> the blocker there was that we haven't reached consensus with the upstream yet, so I was reluctant to diverge :/
[15:48] <slangasek> ev, bdmurray: what's surprising is the large number of reports of it *being* locked, all of a sudden
[15:49] <slangasek> Why should users not be seeing locked /etc/passwd until installing whoopsie?  Is it just that the stale lock has been there for years, but nothing has tried to add a new user on upgrade?
[15:50] <infinity> Could be that.
[15:50] <infinity> We don't add new users all that often.
[15:50] <infinity> Unless you install something that does so, of course.
[15:51] <cjwatson> Quite a few packages add users; odd that whoopsie would be a particularly common victim
[15:51] <slangasek> so unless we think whoopsie is somehow misbehaving and *causing* the lock, the right thing to do is to fix the underlying lock
[15:51] <slangasek> cjwatson: quite a few packages in the default desktop install that will add them on upgrade?
[15:51] <cjwatson> I suppose it could be like man-db being victimised by trigger bugs
[15:52] <cjwatson> Maybe not upgrade, no, though whoopsie's surely not the first
[15:52] <cjwatson> Well, first in this case :)
[15:52] <cjwatson> Anyway, I see no relevant misbehaviour in whoopsie.postinst
[15:52] <slangasek> yep
[15:53] <slangasek> and whoopsie certainly shouldn't be working around the lock if it's not buggily causing it in the first place
[15:53] <slangasek> so the thing to do is to get the lock cleared (e.g., at boot)
[15:53] <slangasek> cjwatson: any objections to clearing that lock file at boot?
[15:54] <cjwatson> Seems fair
[15:54] <infinity> Seems reasonable (ish) to me, if we've confirmed that shadow/passwd inconsistency is avoided in other ways.
[15:54] <slangasek> ok
[15:54] <slangasek> bdmurray: any others?
[15:54] <ev> https://errors.ubuntu.com/ still lists that python-central bug, which has been floating near or at the top since release. Don't know if it's my parsing of the launchpad crash bugs data being broken or if we really still don't have a bug reported for it.
[15:54] <bdmurray> Is that thought that there may be some deliquent package leaving the lock?
[15:54] <ev> apols for jumping in there
[15:55] <infinity> ev: doko uploaded a fix, we just need to get it through SRU land.
[15:55] <ev> https://errors.ubuntu.com/oops/00104e3a-9071-11e1-b51d-2c768aafd08c
[15:55] <ev> ah yay
[15:55] <infinity> ev: And his fix *did* reference a bug, so maybe your matching isn't working?
[15:55] <ev> well it will only match apport filed bugs
[15:55] <infinity> I think it was.
[15:55] <ev> okay, I'll have a look then
[15:55] <ev> I'm sure I'm failing to parse a special character properly
[15:56] <slangasek> I thought doko hand-filed the bug
[15:56] <infinity> ev: https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/955936
[15:56] <ev> cheers
[15:56] <infinity> slangasek: Nope.
[15:56] <slangasek> bdmurray: well, one of the scenarios that caused the lock was if there's a crash while using the guest session
[15:56] <slangasek> bdmurray: so there's a bug there somewhere, but I wasn't able to spot it when I looked at the time
[15:57] <infinity> slangasek: Yeah, one might wonder why the guest session is locking passwd?
[15:57] <ev> infinity: added a note to investigate - thanks
[15:57] <slangasek> infinity: yep
[15:57] <bdmurray> ev: is it because the bug has a python traceback and the error doesn't?
[15:57] <slangasek> infinity: where exactly is the fix for bug #955936?  it's not in the unapproved queue
[15:58] <cjwatson> it's in -proposed
[15:58] <infinity> slangasek: Accepted.
[15:58] <infinity> ^
[15:58] <slangasek> oh
[15:58] <slangasek> sorry, was confused by the 'in progress'
[15:58] <slangasek> which is from the wrong task
[15:58] <cjwatson> I guess we'll auto-copy it to quantal once it's verified
[15:58] <slangasek> ok then
[15:58] <ev> bdmurray: no, the signatures are not matched somehow. I think it's because I'm incorrectly parsing the signature on our end to what people.canonical.com/~ubuntu-archive/apport... is expecting
[15:59] <bdmurray> slangasek: that's all I had for bugs
[15:59] <slangasek> ok, thanks
[15:59] <slangasek> [TOPIC] AOB
[15:59] <slangasek> one minute, talk fast ;)
[15:59] <ev> Some crash database statistics for you:
[15:59] <ev>   - 5,066,166 crashes received since March 20th. That's right, 5 million.
[15:59] <ev>   - 263,280 crashes received on release day and 426,729 the next day.
[16:00] <ev>   - Thanks to having to constantly purge the cache, we're retracing one 12.04
[16:00] <ev>     crash every 47.44 seconds. Our best time was on release day with a full
[16:00] <ev>     cache. We retraced one crash every 25.15 seconds.
[16:00] <ev>   - 8,874 unique problems were seen today (with many instances of those
[16:00] <ev>     seen). Yesterday we saw 12,468 unique problems. Keep in mind that this is
[16:00] <ev>     greatly influenced by how quickly we can retrace crashes (and it currently
[16:00] <ev>     incorrectly places the crashes in the day bucket for today, regardless of
[16:00] <ev>     whether it actually happened days ago and we've only just retraced it). On
[16:00] <ev>     release day we only saw 1,604 unique problems.
[16:00] <ev>   - We've received reports from 364,359 people.
[16:00] <slangasek> wow
[16:00] <ogra_> geez, 5mio !
[16:00] <infinity> Take-home message: (A) we actually have users, (B) software sucks?
[16:01] <slangasek> what's the distribution of duplicates look like?  https://errors.ubuntu.com/ seems to only give a rolling frequency
[16:01] <ev> the retracer hardware is causing serious pain. The numbers will shoot up much higher once we sort that.
[16:01] <xnox> (C) we can now act in more real-time to real problems users are hitting *right now*
[16:01] <ogra_> still if we say we have 20mio users thats like a quater of them having crashes :)
[16:01] <slangasek> i.e., I'm pretty sure there've been more than 858 instances of the python-central issue, and that the number shown was higher yesterday :)
[16:01] <ev> infinity: yes, and yes
[16:01] <cjwatson> (D) maybe we need a more agile SRU process
[16:01] <infinity> cjwatson: Indeed.
[16:01] <ogra_> ++ on that
[16:01] <infinity> cjwatson: Do we have a bikeshed session for that?
[16:02] <slangasek> not currently
[16:02] <ev> slangasek: yeah, the counts look a bit suspicious. I've been investigating but everything checks out so far.
[16:02] <infinity> We probably should.
[16:02] <slangasek> someone want to schedule one?
[16:02] <ev> the code for month and year ranges will land soon
[16:02] <slangasek> infinity: thanks for volunteering :)
[16:02] <ev> in the web ui that is, it's already on the backend
[16:02] <infinity> >:(
[16:02]  * infinity goes to register.
[16:02] <ev> xnox: yes, this is entirely realtime data and we'll soon have realtime updates on the page itself
[16:02] <ev> so you can watch a crash climb
[16:03] <slangasek> ev: well, I'm *sure* the numbers were higher when I loaded the page yesterday - I remember a four-digit count for the top crashers
[16:03] <ev> it's per day at the moment
[16:03] <ev> you'll be able to select month and year soon
[16:03] <ev> and break down by releases, packages, and versions
[16:04] <slangasek> ok
[16:04] <ev> and matthew is working on a mockup UI to be able to select date ranges, I believe
[16:04] <slangasek> would be good to understand things like: what percentage of all crashes does a given crash represent, are users likely to run into this same crash multiple times or just as a one-off, etc
[16:05] <ev> as that was one of skaet 's requirements
[16:05] <ev> slangasek: reply to my email :)
[16:05] <slangasek> heh :)
[16:05] <slangasek> noted ;)
[16:05] <ev> IRC is far too lossy for this sort of thing
[16:05] <ev> cheers!
[16:05] <slangasek> #endmeeting
[16:05] <meetingology`> Meeting ended Wed May  2 16:05:44 2012 UTC.
[16:05] <meetingology`> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-02-15.03.moin.txt
[16:05] <meetingology`> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-02-15.03.html
[16:05] <slangasek> thanks everyone :)
[16:05] <slangasek> see you in Oakland!
[16:05] <stgraber> thanks!
[16:06] <barry> thanks!
[16:06] <jodh> thanks!
[16:06]  * xnox sunny california here we come!
[16:06] <xnox> thanks!
[16:06] <ev> thanks!
[16:06] <highvoltage> yay, sun!
[16:06] <ogra_> thanks!
[16:06] <infinity> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-more-agile-sru-process
[16:06] <ogra_> highvoltage, they call it oracle nowadays
[16:06] <highvoltage> ew, oracle!
[16:08] <slangasek> infinity: schedulimated
[18:58] <AlanBell> evening all
[18:58] <AlanBell> #startmeeting IRC team
[18:58] <meetingology`> Meeting started Wed May  2 18:58:14 2012 UTC.  The chair is AlanBell. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:58] <meetingology`> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:58] <AlanBell> hi all, who is here for the IRCC meeting?
[18:59] <ikonia> present
[18:59] <Myrtti> _o/
[18:59] <oCean> yessir
[19:00] <AlanBell> lets give it a few minutes for others to pop along
[19:02] <AlanBell> hi funkyHat and topyli
[19:02] <topyli> o/
[19:02] <funkyHat> Hi ô/
[19:03] <AlanBell> https://wiki.ubuntu.com/IRC/IrcCouncil/MeetingAgenda
[19:03] <AlanBell> ok, lets get started
[19:03] <AlanBell> we don't have to clear out in a hurry at the end of the hour, but lets try and get through it by then anyhow
[19:04] <AlanBell> #topic Review last meetings action items
[19:04] <AlanBell> #progress people to provide feedback on the ubottu-fr trial on bug 892500
[19:04] <topyli> do we have any?
[19:04] <AlanBell> only a little bit of feedback provided, anyone got anything else to add about ubottu-fr
[19:05] <oCean> Have not really been able to actually test it
[19:05] <oCean> Or more honestly, Ignored it, since it's confusing to have to work with multiple bots
[19:06] <oCean> And I still think that the list with bugs filed for eir is valid for any bot handling our bans/mutes
[19:06] <ikonia> I've fed back on ubuntu-fr, I think it's the way to go
[19:06] <AlanBell> um, ok, but that doesn't help us to get to the goal of not having multiple bots
[19:06] <ikonia> it needs trimming down though
[19:06] <ikonia> but you can only do that once you've picked a direction to develop
[19:07] <oCean> Can we assume, with little feedback there is, others have ignored it too?
[19:07] <AlanBell> ok, I like the idea of using the ubottu-fr code too
[19:08] <AlanBell> that seems likely
[19:08] <topyli> yeah
[19:09] <oCean> I think that is because we are not sure which way we're going
[19:09] <ikonia> yes, pick a path and lets go !
[19:09] <ikonia> get behind it like it or not
[19:09] <ikonia> I'll even shut up about eir if that's the way you want to go
[19:09] <ikonia> but lets get stuck in
[19:09] <oCean> I definitely agree
[19:10] <ikonia> at least there has been discussion this time
[19:10] <ikonia> thought/testing behind it
[19:10] <ikonia> get some opinions etc,
[19:10] <AlanBell> it is something we can maintain as well
[19:11] <ikonia> AlanBell: the work niko has done makes it pretty much "too good" out of the box, so we should be able to trim it back
[19:11] <LjL> i think we can do trials, but either we all say "ok, we're trialling ubottu-fr, so let's ONLY use ubottu-fr for a month [or whatever] and nothing else", or otherwise we'll all continue using what we're used to
[19:11] <ikonia> rather than develop it
[19:11] <ikonia> LjL: yeah, the dual bot thing has confused me a bit
[19:11] <AlanBell> ok, lets move on for now, we will come back to the eir bug in a second
[19:11] <ikonia> lets wade in, one way or another
[19:11] <AlanBell> that is a fair point about not using multiple bots, thats why we moved eir out of the way
[19:12] <ikonia> has it gone ?
[19:12] <AlanBell> so that it would still process expiries
[19:12] <ikonia> I thought we where still supposed to be using it
[19:12] <ikonia> it was still in #ubuntu picking up bans the other day
[19:12] <AlanBell> it is in #ubuntu-ops-monitor
[19:12] <topyli> we just moved the control channel
[19:12] <ikonia> AlanBell: yeah, but it's still picking up bans in #ubuntu, so it's not going to be phased out
[19:12] <ikonia> it's just not spamming #ubuntu-ops-team any more
[19:12] <topyli> right
[19:12] <AlanBell> well it will pick them up if it is there
[19:13] <AlanBell> but it is mainly there so that it will remove bans
[19:13] <ikonia> can we dump it out of ubuntu for a while ?
[19:13] <oCean> Sure, most of us are still using eir
[19:13] <ikonia> oCean: that's why LjL's point is valid
[19:13] <oCean> yep
[19:14] <AlanBell> if someone has a ban set to expire in 30 days or so and we remove eir altogether then that removal won't get processed
[19:14] <ikonia> could the council have a little think please and knock up a draft plan ?
[19:14] <jussi> it makes sense to use code that already fits with supybot if we are aiming for a single bot solution
[19:14] <ikonia> AlanBell: could we not say "we'll work it out manually for a while"
[19:14] <ikonia> just to phase it out, we can always phase it back in if it's decided eir is the way forward
[19:15] <LjL> i don't think eir needs to be removed, just for it to be made clear that it's not the one to be used (if it's decided so)
[19:15] <ikonia> one way or another we'll have to deal with those bans
[19:15] <ikonia> LjL: but it picks up every ban
[19:15] <ikonia> it will still have it in the database and the default nag of 2 days option (or whatever it is)
[19:15] <oCean> AlanBell: I can still update the overview on somedom, so we can see which ban has expired
[19:15] <oCean> then remove manually
[19:16] <ikonia> is there a way to put it into read only mode
[19:16] <ikonia> so it doesn't pickup anything new ?
[19:16] <AlanBell> probably not
[19:16] <oCean> Also, I think eir can still remind us of exired bans even when eir is not in #u
[19:16] <AlanBell> not without affecting other channels
[19:16] <ikonia> ahhh of course
[19:16] <ikonia> didn't think of the other channels
[19:16] <funkyHat> How many bans are likely to be in eir? Would it be feasible to move them manually to ubotu-fr after disabling eir in #u?
[19:17] <oCean> funkyHat: currently 107
[19:17] <funkyHat> Or script it if we can get a detailed enough output from eir
[19:17] <ikonia> funkyHat: oCean 's script run weekly until they are phased out would probable work simpler
[19:17] <ikonia> just review on a sunday or something for a month or two
[19:17] <funkyHat> Ok
[19:17] <ikonia> hell, I'll take an action to do it if needed
[19:17] <AlanBell> sounds good
[19:17] <oCean> exactly
[19:18] <topyli> i'd be fine with that
[19:18] <ikonia> it's not exactly a long term issue, and probably just a simple way of phasing it out
[19:18] <funkyHat> Yep, sounds good
[19:18] <AlanBell> what is the overlap between ubottu and ubottu-fr? Can we put bits of ubottu-fr into ubottu easily?
[19:19] <ikonia> as I recall niko basically did a modular hot swap
[19:19] <ikonia> so you can swap in / out what you want
[19:19] <ikonia> ubottu-fr was just a snapshot of ubottu's later code from what I recall
[19:19] <LjL> do we want to phase it out before we know whether ubottu-fr is "good enough", though? do most of us currently know anything about ubuntu-fr? i'm still leaning towards something like yelling at every op "use ubottu-fr instead of eir for a month!", but without killing eir immediately
[19:20] <tsimpson> that depends on how ubottu-fr works, ubottu is a regular supybot with plugins. so as long as all the code is external to supybot, it should be fine
[19:20] <LjL> ikonia: no, i don't think it is just that. it has been modified (the supybot core, that is) to my knowledge
[19:20] <LjL> the good news, i seem to recall, is that the modifications are being pushed upstream (to supybot)... don't quote me on that, it's what i seem to recall hearing
[19:20] <ikonia> LjL: I don't know, so I'm not stating anything factually
[19:20] <AlanBell> ok, we need to have a chat with niko about this
[19:21] <tsimpson> heh, good luck getting anything upstream in supybot
[19:21] <niko> there is some core changes in ubotu-fr, that means, you can't use channel plugin of ubotu-fr without the full bot, but that means too that you can load any kind of ubottu plugin into ubotu-fr
[19:22] <AlanBell> oh that sounds fine then
[19:22] <LjL> niko: yeah, it's inconvenient, though, to rely on a non-standard supybot. should we need to put a bot up quickly, we can't just apt-get supybot or whatever
[19:22] <oCean> But LjL has a point, with so little review/trials done on ubotu-fr, how much do we trust it, to replace eir, and actually remove eir from #u
[19:22] <AlanBell> so we can load all the ubottu plugins into an ubotu-fr clone and bring it up as ubottu
[19:22] <niko> wget the tar files, sudo python setup.py install, and that's all
[19:23] <funkyHat> So what are the issues with getting ubotu-fr code into supybot?
[19:23] <ikonia> tsimpson: I'm guessing you've had a tough time getting anything upstream ?
[19:23] <niko> ubotu-fr code is dedicaced for ircd-seven, that's the big point
[19:23] <tsimpson> ikonia: upstream seem dead
[19:23] <ikonia> ahh
[19:23] <ikonia> so very hard then
[19:24] <oCean> aren't we getting a little ahead with discussing merges etc?
[19:24] <ikonia> niko: would it be possible to make that part a "module" rather than part of the code base
[19:24] <ikonia> oCean: sorry, yes
[19:24] <ikonia> I got excited
[19:24] <topyli> why not fork it properly then, if upstream is not maintaining the original?
[19:24] <niko> ikonia: not really, too much stuff need to be done in core files, due to how supybot was written
[19:24] <tsimpson> topyli: because the code is both insane, and ugly
[19:25] <topyli> ok :)
[19:25] <oCean> if we trust current ubotu-fr enough, I say remove eir, bring ubotu-fr in, and run,test,file bugs, etc
[19:25] <ikonia> I have the impression tsimpson may not have had a good time
[19:25] <AlanBell> yeah, I think we need to jump in with both feet here
[19:26] <AlanBell> we also need to get through this meeting :)
[19:26] <oCean> Is there a manual/usage wikipage of some sorts on ubotu-fr usage?
[19:26] <niko> http://nicolas.coevoet.fr
[19:26] <AlanBell> I will mail the list with a plan to set up an ubottu-fr clone with the ubottu plugins loaded and get it to replace ubottu
[19:27] <oCean> niko: I see very few lines under usage :)
[19:27] <AlanBell> we can discuss on the mailing list and at UDS for those going or attending remotely
[19:27] <oCean> OK
[19:27] <AlanBell> lets crack on with the agenda now
[19:27] <AlanBell> #topic Open items in the IRCC tracker
[19:27] <AlanBell> there are none \o/
[19:27] <AlanBell> #topic Review Bugs related to the Ubuntu IRC Council
[19:27] <topyli> yay!
[19:27] <AlanBell> #subtopic bug 788503 IRC Guidelines too #ubuntu centric - tsimpson
[19:28] <AlanBell> ok, I put the text we had on the wiki
[19:28] <topyli> yeah, thanks for that
[19:28] <AlanBell> https://wiki.ubuntu.com/IRC/Guidelines has been updated
[19:28] <topyli> it is improved
[19:28] <AlanBell> I think it is better than it was, if there are further improvements to be made then great, we can make them on the wiki
[19:29] <topyli> yes
[19:29] <funkyHat> So is this done? ⢁)
[19:29] <AlanBell> I will close that bug now
[19:29] <AlanBell> fix released
[19:29] <AlanBell> #subtopic bug 884671 Ubuntu IRC operator recruitment is slow and ungainly - jussi
[19:30] <AlanBell> so for this one we have a new procedure of processing applications from existing core ops as fast as we can conveniently do it
[19:30] <topyli> this is streamlined a bit with the fast approval of "old" ops
[19:30] <topyli> yes
[19:31] <AlanBell> I think we have one to do from a couple of days ago, but generally we are responsive on this now
[19:31] <AlanBell> I also want to do a big call for ops for lots of channels and process all the queues to do an intake of operators for the Quantal cycle
[19:31] <AlanBell> and generally have an intake at the start of each development cycle
[19:32] <AlanBell> I think that makes operator recruitment regular and quite gainly
[19:32] <AlanBell> so I think that bug is fixed :)
[19:32] <topyli> we could compile a list of channels and simply send out a call for ops. it's been a while
[19:33] <AlanBell> yup, and it is the start of the cycle
[19:33] <topyli> yes
[19:34] <LjL> Just for the record: I still think you should have a "procedure" (or lack of one, whatever makes it happen) for appointing ops outside of a semestral recruitment process or whatever. And I'm not sure I see how a new release makes new ops automatically needed, on the other hand. But this has been discussed a lot before, so I'm just saying this for the logs, basically.
[19:34] <topyli> we can close the bug
[19:34] <AlanBell> fix released
[19:35] <AlanBell> noted LJL
[19:35] <AlanBell> #subtopic bug 892500 eir is still not fit for purpose in #ubuntu -ikonia
[19:35] <AlanBell> so on this one we look like going in the ubotu-fr direction, I will mail the list and get some actions together for this.
[19:36] <AlanBell> #subtopic bug 913541 there are a number of people with Ubuntu IRC cloaks who have expired from the ubuntumembers group
[19:36] <ikonia> yeah, the ubottu-fr plan covers this
[19:36] <AlanBell> Pici: did you get anywhere with this one?
[19:37] <AlanBell> um, pici hasn't said anything, maybe he is indisposed
[19:37] <AlanBell> lets move on
[19:37] <AlanBell> #subtopic bug 916247 devel wiki on ubottu.com needs some attention
[19:38] <AlanBell> well this was full of spam, that got cleared up and locked down, migrating the data to wiki.ubuntu.com might be a good idea, but the formatting will need a lot of manual fixing and nobody is leaping forward to take on that rather dull task
[19:38] <ikonia> I can help with it, I can't "do" it
[19:38] <ikonia> the ubuntu wiki is a tough mistress
[19:38] <AlanBell> the bug was the spam, which has been addressed, I don't think the devel wiki in itself is a major overhead to have just sitting there
[19:39] <AlanBell> I am inclined at this point to just leave it and close the bug
[19:39] <topyli> moving the content is a different issue really
[19:40] <AlanBell> ok, commented and [C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C fix released then
[19:40] <AlanBell> oops
[19:40] <topyli> ok
[19:40] <AlanBell> right, moving on
[19:41] <AlanBell> #topic end of the induction/probation period for the current intake of operators
[19:41] <topyli> oh it's time is it?
[19:41] <AlanBell> so we have a bunch of operators from the #lubuntu area who are at the end of their 3 month intro period
[19:42] <AlanBell> there have been a couple of resignations from people who for various reasons decided not to continue and I think one of them never showed up at all
[19:43] <AlanBell> we should email them individually I think
[19:43] <Myrtti> remind us of the nicknames again?
[19:43] <Myrtti> or shhould I go check myself :-P
[19:43] <AlanBell> https://launchpad.net/~irc-lubuntu-ops/+members#active
[19:44] <topyli> i haven't noticed any serious worries with the lubuntu ops. those who are not active are another story
[19:45]  * AlanBell tidies up a couple
[19:46]  * Myrtti nods
[19:46] <AlanBell> anyone know m0hi?
[19:47] <topyli> not me
[19:47] <Unit193> AlanBell: IAmNotThatGuy
[19:47] <AlanBell> oh, I have seen that nick
[19:48] <Sidewinder> IAm... is currently in #ubuntuforums
[19:48] <Sidewinder> Shall I ask him to join here?
[19:48] <AlanBell> Sidewinder: that would be great
[19:48] <ikonia> is he active in #lubuntu ?
[19:48] <Sidewinder> K
[19:48] <Myrtti> he's on the channel
[19:49] <Myrtti> there hasn't been that much need for ops there...
[19:49] <Myrtti> then again I can't remember if he was on the lesson at -classroom either, and I don't know if he needs it
[19:49] <topyli> oh maybe i should apply there myself, i like that kind of channels
[19:49] <AlanBell> yeah, I don't have any concerns really, as an Ubuntu Member
[19:50] <Sidewinder> AlanBell, I politely paged IAmNot ThatGuy
[19:51] <AlanBell> ok, thats fine, will chat later, I don't have any concerns really
[19:51] <Myrtti> idle 29minutes
[19:51] <Unit193> (There is no meeting directly after this)
[19:51] <AlanBell> ok, lets move on
[19:51] <AlanBell> #topic Calling for new operators
[19:51] <AlanBell> ok, new cycle new intake of operators
[19:52] <topyli> yes let's just do it
[19:52] <funkyHat> Yep
[19:52] <AlanBell> I will update my list of everyone in the queue and do a call for ops
[19:52] <AlanBell> then we can process the queues and get a new group in
[19:52] <topyli> ok
[19:52] <AlanBell> #action AlanBell to sort out a call for ops
[19:52] <meetingology`> ACTION: AlanBell to sort out a call for ops
[19:52] <Myrtti> which channels are we looking for?
[19:53] <Myrtti> and do you want me to redo my classroom?
[19:53] <AlanBell> pretty much all the core channels and yes please Myrtti
[19:54] <AlanBell> and I want to get a few more classroom sessions scheduled too
[19:54] <topyli> you did have a good subject which you might do every now and then if you have the energy
[19:54] <Myrtti> may I suggest a specific call for certain timezones?
[19:54] <AlanBell> good point, what times are in need of coverage?
[19:55] <Myrtti> I think nighttime Europe is always in need
[19:55] <Myrtti> few extra eyes wouldn't be bad
[19:55] <topyli> so, pacific america?
[19:55] <AlanBell> ok, kind of 00:00 to 08:00 UTC
[19:56] <Myrtti> topyli: or au/nz/jp
[19:56] <AlanBell> doesn't really matter where people actually are, just what time they are on IRC
[19:56] <Myrtti> depends on the viewpoint
[19:56] <Myrtti> exactly
[19:56] <topyli> yeah :)
[19:56] <AlanBell> ok, I will put something about that in the call for ops
[19:56] <AlanBell> ok, moving on
[19:56] <AlanBell> #topic alignment of launchpad teams and channel access lists
[19:57] <AlanBell> right now the access lists and launchpad teams are in approximate agreement at best
[19:57] <AlanBell> https://docs.google.com/spreadsheet/ccc?key=0Ankl5FhsdSiZdGZVV2ZuLVRwa2c5M3pqX3BEaUhXMFE
[19:57] <AlanBell> is all the access lists
[19:57] <topyli> someone was helping with this, no?
[19:57] <AlanBell> anyone who pms me an email address can have edit access to thi
[19:58] <AlanBell> knome was helping to identify some issues
[19:59] <AlanBell> I was thinking of doing a bit of automation to get the launchpad groups and the access lists in the spreadsheet side by side
[19:59] <AlanBell> then we can make them all match up
[19:59] <ikonia> hasn't Pici done work on this before
[19:59] <ikonia> maybe worth checking
[19:59] <EvilResistance> AlanBell:  i see one flaw there, though: not every nickname that patches on Launchpad is up-to-date here on Freenode
[20:00] <EvilResistance> s/patches/is/
[20:00] <AlanBell> EvilResistance: that is a good point, but everyone in the core ops team does have a nick on their launchpad page (I checked)
[20:00] <AlanBell> if any don't tie up I will be asking them to change the launchpad nick to their account name
[20:00] <EvilResistance> indeed, just wanted to point that out, you'd need to make sure the nicks are kept up to date ;)
[20:00] <AlanBell> it is done on account names rather than nicks
[20:00] <topyli> isn't it a requirement in the first place, so you can be an op? :)
[20:01] <AlanBell> account  : Resistance
[20:01] <Resistance> :P
[20:01] <AlanBell> ok, don't need to go through the spreadsheet line by line right now
[20:02] <AlanBell> oh, one thing
[20:02] <AlanBell> VotiA or VotriA or something else as the default? should it be the same over all channels?
[20:02] <AlanBell> and should people have founder flags?
[20:03] <AlanBell> some channels have a wide assortment of flags for operators, it looks a bit messy but I guess it works fine
[20:03] <Resistance> AlanBell:  from an ITSec point of view, i think that only members of IRCC should have the founder flag, anyone else who has founder flag has sort of a god power over a channel.
[20:04] <topyli> i think we've just done VotiA, but i'm far from clueful in this
[20:04] <AlanBell> ok, we will have a bit of a think about this and work out some conventions I think
[20:04] <topyli> yeah i agree, ops don't need founder flags
[20:04] <AlanBell> bit of a pici question
[20:04] <AlanBell> #topic UDS blueprint
[20:05] <AlanBell> so UDS is coming up next week
[20:05] <AlanBell> I am going in person, anyone else going to be there?
[20:05] <Myrtti> Resistance +1
[20:06] <topyli> just remote lurking. i'll probably be semi-actively following the community track
[20:06] <Myrtti> wasn't sponsored, so not going
[20:06] <AlanBell> would you like to have an IRCC session set up so we can have a chat over the audio streaming thingie?
[20:07] <topyli> why not, if we have something to chat about :)
[20:07] <AlanBell> ok, I will set one up then, I will try to get a morning slot for it
[20:08] <AlanBell> #action AlanBell to schedule UDS session
[20:08] <meetingology`> ACTION: AlanBell to schedule UDS session
[20:08] <AlanBell> #topic setting up an election of another council member
[20:08] <AlanBell> there are 4 people on the IRCC, there should be 5 according to our charter
[20:08] <topyli> yeah
[20:09] <AlanBell> we deferred fixing that into the Q cycle but I think we are now in a much better position to go ahead with it
[20:09] <funkyHat> And we are now in the Q cycle ⢁D
[20:09] <topyli> we need to feel around for candidates
[20:09] <Myrtti> I'm happy I'm practically unelectable \o/
[20:09] <AlanBell> \o/
[20:10] <Myrtti> I can continue to heckle from the peanut gallery
[20:10] <AlanBell> mmm peanuts
[20:10] <Unit193> Yep, we can toss the peanuts at them. :D
[20:10] <funkyHat> I know of one potential candidate, and I remember someone else being mentioned too
[20:10] <AlanBell> ok, not much more to say on this one, just wanted to announce it and get started on it
[20:11] <AlanBell> we will talk to the CC about the process
[20:11] <AlanBell> final item now
[20:11] <AlanBell> #topic set up #ubuntu-discuss for on-topic non-support discussion and ramblings
[20:11] <AlanBell> we have had Canonical sending people into #ubuntu to join the discussion about ubuntu
[20:12] <AlanBell> people who don't have an active support problem
[20:12] <Myrtti> #ubuntu-project
[20:12] <AlanBell> this isn't ideal so we talked to canonical about this issue and got it fixed
[20:12] <AlanBell> but it would be nice to have an area for on-topic talk about ubuntu that isn't support
[20:12] <AlanBell> and isn't what -offtopic is
[20:12] <ikonia> that was always my dream for -offtopic
[20:13] <LjL> you can kill #ubuntu-offtopic, or you can talk about interesting things there and make it better, your call i guess
[20:13] <ikonia> option 2 is always my preference
[20:13] <topyli> i'd use -ot
[20:14] <topyli> or *continue* to use -ot, rather
[20:14] <ikonia> I would if you could have a discussion in there
[20:14] <funkyHat> It is quite possible to have a discussion in -ot
[20:15] <AlanBell> well right now it is being used for a perfectly nice conversation about films
[20:15] <Sidewinder> Unless you want to create an #ubuntu-offtopic-offtopic, which I wouldn't recommend.
[20:15] <AlanBell> Sidewinder: more of an #ubuntu-ontopic
[20:16] <Sidewinder> Not a bad idea; just non-support..
[20:16] <AlanBell> I don't want to remove #ubuntu-offtopic
[20:16] <LjL> so you want a channel for support, a channel for Ubuntu discussions that are not support, and a channel strictly for discussions that are not about Ubuntu
[20:16] <LjL> seems overkill to me
[20:16] <LjL> and a good way to kill either or both the "secondary" channels
[20:16] <Sidewinder> There is that.
[20:17] <topyli> i think -ot is just fine for any ubuntu-related discussion. you're not required to talk about flashlights there. it's just for whatever is not support
[20:17] <AlanBell> it is possible that it won't be a viable channel long term, I don't know without trying it
[20:17] <Sidewinder> I don't feel that ot is overly busy.
[20:17] <guntbert> maybe make it more obvious in -ot that is is intended for discussion about ubuntu - not just a general "anything goes"
[20:17] <funkyHat> I don't see much issue with encouraging more ubuntu-related discussion in -ot. At the moment it's not a terribly busy channel
[20:17] <LjL> guntbert: well but it's not. it's for both things
[20:18] <funkyHat> guntbert: well it is a general channel too
[20:18] <guntbert> LjL: ok, (I said 'not just' :-)
[20:18] <Sidewinder> If it ain't broke, don't fix it. IMHO
[20:19] <topyli> it's not broken. sure, we could always tend to it better, but that's not the channel's fault as such
[20:19] <AlanBell> "Join the discussions in #ubuntu on Freenode" is what the canonical stuff said
[20:19] <guntbert> I see one problem: quality discussion just don't happen there - do they?
[20:19] <AlanBell> "Join the discussions in #ubuntu-offtopic on Freenode" would be a strange thing for them to say to customers
[20:19] <topyli> quality discussion does happen in -ot. just not all the time
[20:19] <LjL> so the issue is the channel name?
[20:19] <topyli> AlanBell: that's true
[20:20] <Sidewinder> guntbert, I think they do; it's not just limited to that.
[20:20] <Sidewinder> LjL, I think the name's fine, but that's just me.
[20:20] <AlanBell> LjL: partly, yes, and partly because someone arriving in a totally off-topic discussion might be confusing
[20:21] <topyli> canonical could say "join #ubuntu for support and #ubuntu-offtopic for general discussion"
[20:21] <funkyHat> I think arriving to see an off topic discussion is better than joining a dead channel
[20:21] <LjL> AlanBell: make #ubuntu-chat or #ubuntu-discuss or whatever and redirect it to #ubuntu-offtopic if the issue is the channel name in "marketing", i don't think that's an issue. if the problem is the content, well i don't think it's an issue either, but i guess it might be
[20:21] <guntbert> how about doing it the freenode way?   #help = #freenode              so #ubuntu-offtopic = #ubuntu-discuss
[20:21] <Sidewinder> topyli, I think that's THE answer.
[20:21] <Resistance> i think topyli has the right idea there
[20:21] <funkyHat> Maybe if -ot gets too crowded we could rethink having a -discuss or -project channel
[20:22] <funkyHat> (assuming some of the crowd is actually project related ;)
[20:23] <guntbert> I too like topyli's proposal
[20:24] <funkyHat> Yep
[20:24] <AlanBell> how much of the crowd at the moment is made up of people who are developers on the project in some way?
[20:24] <ikonia> pretty much zero
[20:25] <Resistance> what ikonia said, at the most maybe 1%
[20:25] <topyli> in -ot? not too many
[20:25] <ikonia> offtopic has nothing to do with ubuntu in any way
[20:25] <ikonia> even community
[20:25] <ikonia> people don't user/support/discuss ubuntu, it's just another defocus
[20:25] <Myrtti> most of the time it feels like -uk is better for that discussion ;-)
[20:25] <ikonia> Myrtti: it is
[20:25] <AlanBell> yup
[20:26] <topyli> i'm always talking about ubuntu or linux in -ot
[20:26] <Myrtti> s/that//
[20:26] <topyli> except when i'm talking about something else :)
[20:26] <Sidewinder> Heh,.
[20:26] <ikonia> topyli: yes, your a rarer beast, as is ljl and a few others
[20:26] <ikonia> but a lot of the users have no "ubuntu" reason to be there
[20:27] <AlanBell> and lots of people who do some contribution to ubuntu in some context don't really want to be there
[20:27] <topyli> there are a lot of people there who don't even use ubuntu anymore, but used to at some point and just like the people
[20:27] <ikonia> topyli: I don't think you have to use it, but have an interest in it, follow it, be aware of it so you can actually participate
[20:27] <ikonia> be "involved" in someway
[20:27] <AlanBell> both are fine, I don't want to go shutting down -offtopic as a kind of defocusy chatter place
[20:28] <topyli> ikonia: it would be more "ubuntu" that way for sure
[20:28] <AlanBell> a lot of loco teams don't have active channels so -offtopic kind of takes that role a bit
[20:28] <Sidewinder> Currently it's just less strict.
[20:28] <ikonia> topyli: at the moment there is no "ubuntu" community to that channel, beyond the fact that it has the ubuntu coc
[20:28] <ikonia> it's not made up of members/users/interested parties etc, its just people
[20:29] <ikonia> you could chnge the channel name to offtopic and it would not have any difference to the users/content
[20:29] <dax> If memory serves, the top three people in that channel don't use Ubuntu; topyli breaks the trend by being in 4th place :P
[20:30] <ikonia> I don't think using it is a requirement
[20:30] <Myrtti> topyli: have you moved back to Ubuntu now?
[20:30] <Myrtti> :-P
[20:30] <topyli> i'm back on ubuntu yes :)
[20:30] <ikonia> but being part of the community, following it's disucssion/development etc
[20:30] <ikonia> being able to join in with it in some way
[20:30] <dax> I will refrain from discussing my opinions on whether AtomicSpark is part of the Ubuntu community, but I don't think I (#2) am :P
[20:31] <AlanBell> ok, so how do we draw this item to a conclusion?
[20:31] <topyli> yeah you're an example of someone who *was* a part of the community for a long time and now just hang in there with old friends :)
[20:32] <topyli> AlanBell: well, frankly i'd do nothing but tell canonical to clarify their message
[20:32] <Sidewinder> Homeostasis?
[20:32] <Sidewinder> topyli, +1
[20:33] <Resistance> I'm not on the Council, but I think that, at the least, telling Canonical to clarify their message is the first step, but that more in-depth research and discussion on this topic needs to be done to determine whether an Ubuntu discussion channel needs to exist separate from -offtopic
[20:33] <Sidewinder> If we were voting, that is..
[20:33] <topyli> maybe it will improve -ot if canonical starts sending people there, who are actually interested in discussing ubuntu
[20:33] <funkyHat> I agree. And if we want to have more ubuntu related discussion in -ot we need to just have more ubuntu related discussion
[20:33] <funkyHat> Yes
[20:33] <AlanBell> well I did that, and Mark said
[20:33] <AlanBell>  * if there is a better IRC channel for general "hello, I'm interested in X with Ubuntu, where should I go?", then let me know and I'll update the team to use that for the cases where they do judge the audience to be developer or at least highly technical in nature.
[20:33] <AlanBell> the other option is that canonical don't send people to IRC
[20:33] <AlanBell> and send them to askubuntu.com or something instead
[20:33] <Resistance> AlanBell:  that'd be cutting out one of the big support communities, there.
[20:33] <topyli> well the latter one does not sound very good
[20:35] <Resistance> i think IRC is better for real-time support, askubuntu.com and ubuntuforums.org take some time to actually get decent responses, and to be honest, there's more people on IRC who really know what they're talking about
[20:35] <Resistance> (at least, in comparison to askubuntu.com)
[20:35] <AlanBell> it isn't about support
[20:35] <topyli> also, it's not *so* terrible to come to the main channel, it's natural. it's just that people will use their energy to guide these people to the correct channels like -ot or -server or whatever
[20:35] <topyli> i don't know how big this problem is for #ubuntu
[20:35] <AlanBell> this was about their communications around ubuntu for android
[20:36] <topyli> is there *any* channel where people talk about ubuntu for android?
[20:36] <topyli> does it even have anything to do with the community?
[20:36] <LjL> ^
[20:37] <LjL> maybe the problem is that Canonical and its developers should interact with the community, not "send" people to IRC when there's no way anyone can have a clue about the product
[20:37] <dax> Does it have publicly accessible source-code anywhere?
[20:37] <dax> (because if not, it's not an Ubuntu community project, it's a Canonical project using Ubuntu branding)
[20:38] <AlanBell> http://paste.ubuntu.com/963188/
[20:38] <AlanBell> silly pastbin with no wrapping
[20:38] <topyli> ubuntu one has nicely settled on its own channel, it's not bothering us too much i think
[20:38] <topyli> at least that's how it used to be
[20:39] <AlanBell> so yes, there should be more canonical developers involved, but no they are not going to all join #ubuntu-offtopic and stay there
[20:39] <topyli> probably not. they have jobs :)
[20:40] <Myrtti> this might be something that could be discussed in UDS...
[20:40] <AlanBell> that is a good point
[20:41] <AlanBell> get some more canonical opinions on the matter too
[20:41] <topyli> yes. the devs will be there
[20:41] <Myrtti> indeed
[20:41] <AlanBell> ok I will put it on the agenda of the UDS meeting
[20:41] <Sidewinder> AlanBell, What's wrong with them joining #u? I for one have noticed some questions asked there that were not answered and I could not.
[20:42] <Myrtti> Sidewinder: there is nothing to support
[20:42] <AlanBell> Sidewinder: because they don't have a support question and the general feeling at the time was nobody wanted people turning up in #u wanting to "join the conversation"
[20:42] <LjL> Sidewinder: that Ubuntu's policy has always (to my knowledge) been that it's a technical support channel only, not for opinions, information about products, discussion, etc - if we opened *that* door, a lot of stuff would come in
[20:42] <Myrtti> Sidewinder: so it doesn't fit on a support channel at the moment
[20:43] <AlanBell> anyhow, lets discuss that more next week
[20:43] <Sidewinder> OIC.
[20:43] <AlanBell> #topic Any Other Business
[20:43] <AlanBell> anything else to discuss now?
[20:43] <Myrtti> AlanBell: #ubuntu+1
[20:43] <Myrtti> (see -ops)
[20:43] <AlanBell> ah right, shall we open it again?
[20:43] <topyli> if Q is open, why not?
[20:43] <AlanBell> can't see any particular reason no to, the toolchain is open
[20:43] <Sidewinder> LjL, I agree.
[20:44] <AlanBell> lets do it
[20:44] <topyli> yeah
[20:44] <AlanBell> ok, anything else
[20:44] <oCean> AlanBell: One more thing, since you skipped quite quickly through the "eir not fit for purpose"
[20:44] <oCean> Recently I removed a lot of bans/mutes. Most of those had no comments at all, so I had to go through logs etc to see if they could be removed
[20:44] <oCean> Because I don't really want to go through all that again, and we don't want to do that if we're weekly reviewing which bans can be removed, I suggested changing eir's config (or for any new bot) to autoremove-after-expire.
[20:45] <AlanBell> ok, I think if people are not commenting on bans they are fair game for removal
[20:45] <oCean> So if you want a ban/mute to stay, just make sure you btset it with an expire date and/or comment, or after 2 days it is gone and so preventing all these undocumented bans
[20:45] <oCean> we can agree, but others should be aware of it
[20:45] <oCean> since even after a couple of days, we have lots of expired and uncommented bans again
[20:46] <topyli> sounds good to me. an email to the list should handle the communication
[20:46] <oCean> yup
[20:46] <topyli> oCean: are you volunteering to compose this email? :)
[20:47] <oCean> sure, but it would not go out before the weekend
[20:47] <topyli> because you would know what you're talking about, unlike me
[20:47] <oCean> don t think we're in a hurry though
[20:47] <topyli> ok
[20:48] <AlanBell> fine
[20:48] <AlanBell> anything else to discuss?
[20:48] <AlanBell> #endmeeting
[20:48] <meetingology`> Meeting ended Wed May  2 20:48:42 2012 UTC.
[20:48] <meetingology`> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-02-18.58.moin.txt
[20:48] <meetingology`> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-05-02-18.58.html
[20:48] <AlanBell> thanks everyone
[20:48] <oCean> \o/
[20:48] <topyli> nice, lots done
[20:48] <Sidewinder> Thank you, all.
[20:49] <AlanBell> lots of bugs closed :)
[20:49] <funkyHat> woo
[20:49] <funkyHat> Thank you everyone
[20:49] <Myrtti> please poke iceroot on -ops when +1 is open


[04:08] <polll> hey any1 know why following this tutorial on 15.10 renders ubuntu un-bootable? http://yarenty.blogspot.ca/2014/08/how-to-fix-macbook-pro-touchpad-on.html       I ran 'systemctl  restart lightdm' and I haven't been able to boot into ubuntu since. Im using refind and 15.10 on a Macbook pro.  I eventually booted on a live USB stick, and removed the lines of cod
[04:08] <polll> e I added to that file (from the tutorial) (on the actual ubuntu, not my live usb's filesystem). Still no luck. I installed boot-repair on the liveusb, but only generated a report to pastebin as I wasn't sure if running it would be the best choice of action as of yet. the report is here (https://paste.ubuntu.com/15021793/). I should probably add that by unbootable i mean it hangs at a terminal screen with "fsck from util-linux 2.26.
[04:08] <polll> 2" at the top. 2nd line is "/dev/sda5:clean, 460106/3112960 files, 3043774/12450560 blocks". At first it was hanging on something related to bluetooth. Now it hangs at Starting Light Display Manager... and deal with any system changes.signatures....". Again, if this is a ridiculous question, my apologies. I have very little experience with these types of problems.
[06:46] <darkxst> polll, we dont use lightdm in ubuntu GNOME
[06:47] <darkxst> and there is no reason that would completely break your system (even after removing the file you added)
[06:48] <polll> Right, that was my mistake for entering it. But it still did something. If it helps I'm left hanging with this command "4.402071 Bluetooth: hci0: BCM: Read verbose config info failed (-16)s.signatures......."
[06:51] <darkxst> polll, no I would think something else broke it, but just to make sure you could remove the mtrack package
[06:51] <darkxst> bluetooth error won't break your boot
[06:51] <polll> Okay, thank you. But if I cant boot into Ubuntu how can I remove the package?
[06:51] <darkxst> recovery mode
[06:52] <polll> I can't seem to access recovery mode. I've tried holding shift and it's yielded no results.
[06:52] <polll> Would the Live USB help?
[06:52] <darkxst> you just need to get the timing right, if you hit shift to early the bios probably eats it
[06:53] <darkxst> you could probably do it with the live USB, but may need to set your root via kernel commandline
[06:54] <darkxst> (I'm not really sure what the live usb offers in way of repair modes otherwise, maybe it can be done easier than that)
[06:57] <polll> I'll give the timing another try. I figured it may be of some use to send over a picture so here's where I am at currently: https://imgur.com/LZeawb3
[06:59] <darkxst> polll, are you using Ubuntu GNOME? or just plain Ubuntu?
[07:01] <darkxst> and logs would be far more useful to screenshots ;)
[07:01] <polll> Oh wow. I'm sorry, I may be in the wrong channel. I joined in a hurry and misread GNOME for GRUB. I have the default Ubuntu 15.10 desktop installation. So I'm assuming I'm not in Gnome.
[07:01] <polll> Is the pastebin of any help?
[07:02] <polll> https://paste.ubuntu.com/15021793/
[07:02] <darkxst> no
[07:03] <darkxst> Xorg.0.log might
[07:03] <darkxst> or journalctl output
[07:03] <polll> I can access the file system with the Live USB. How would I go about acquiring this log?
[07:07] <darkxst> /var/log/xorg.0.log
[07:07] <darkxst> not entirely sure if lightdm logs there or not though
[07:09] <darkxst> journalctl needs to be run from a running system, so you could boot into a systemd shell, but again that requires grub and/or setting root= params
[07:12] <darkxst> Noskcaj, can you update your vte merge to latest 0.42.4-1
[07:19] <polll> Right. I'm still not able to access the GRUB menu. But I found a lightdm logs folder. I've copied over those logs. There was a Xorg.0.log but it doesnt have much in it. I'll throw them on pastebin in a second
[07:21] <polll> here;s xorg.0.log,  https://paste.ubuntu.com/15022800/
[07:22] <polll> lightdm.log https://paste.ubuntu.com/15022802/
[07:23] <polll> x-0.log (inside the lightdm folder) https://paste.ubuntu.com/15022804/
[07:24] <darkxst> polll, Parse error on line 1 of section InputClass in file /usr/share/X11/xorg.conf.d/50-synaptics.conf
[07:24] <darkxst> 	"old" is not a valid keyword in this section.
[07:24] <darkxst> thats your problem
[07:25] <polll> I did go back and remove the lines of code I added to that file, though.
[07:25] <darkxst> it must still be there or you corrupted the file somehow
[07:26] <polll> OH WOW
[07:26] <polll> There was a line missing a hashtag to comment it out...
[07:26] <polll> well, this is embarrassing.
[07:28] <darkxst> polll, and it would have been less embarrassing if you were in the right channel ;)
[07:40] <polll> Very true. Stress does wonderful things to people. Thank you so much for your time, patience, and help. I really appreciate it, as this must have been irritating.
[07:41] <darkxst> polll, np
[19:57] <craysiii> counting down the days until 16.04


[07:45] <portmanteau> I just did a clean install of 21.04 and after about 15 minutes the CPU load goes to 100%. I think it's an automatic update but the problem remains even after I uncheck all updates in the software sources control panel.
[07:46] <portmanteau> thanks in advance
 What process consumes so much resources?
 Please use a system monitor to find out. It’s very unlikely that updates are causing that I think
 As Michael explained already, updates are not like in windows. Usually updates will be at least 10 times faster in Lubuntu compared to Windows. So, if updates takes 60 minutes in windows, a compareable update takes 2-5 minutes in Lubuntu for me (re @lubuntu_bot: (irc) <portmanteau> I just did a clean install of 21.04 and after about 15 minutes the CPU load goes to 100%. I think it's an automatic update but the problem remains even after I unc
[13:40] <Guest6269> Bom dia
[13:46] <Kolusion> Clueless amateurs haven't bothered to state anywhere on the O/S's website what the system requirements are. Is anyone able to prove me wrong?!
 If you're smarter than clueless idiots, find out yourself ;)
[13:51] <kc2bez> The system requirements are based on what you plan on doing with your system. The OS will run on pretty much any 64bit processor and as little as 512 MB of RAM.
[13:51] <Kolusion> Thanks. Are you able to show me an official declaration of the system requirements?
[13:51] <kc2bez> No we don't post them any more.
[13:52] <Kolusion> Ok, I see why there are only 48 people in here then. Good bye
 Polite enough
 He could have at least asked "Why" before getting offended 😅
 Well, it's his problem anyway :D
 Hey guy, if you're still here, I can point you to windows 11 system requirements. For free
 They left right after they said bye.
 @ kc2bez Maybe a "minimal system requirements" a another "recommended requirements" (re @lubuntu_bot: (irc) <kc2bez> No we don't post them any more.)
 "recommended requirement for use as office PC"
[14:32] <apt-ghetto> There are some technical limitations such as the settings in calamares (welcome.conf). And I think there might be a problem, if the live-system cannot be loaded into RAM.
 Do you know, what the minimal required RAM is to install and boot Lubuntu?
 And what the minimal disk space to install Lubuntu is? (If you do not know, I am going to test anyways out of curiosity) 😅
 I did it successfully with 512mb on eeepc (re @Halis: Do you know, what the minimal required RAM is to install and boot Lubuntu?)
 Just for "marketing" reason would be interesting to know, if it would boot with 256MB RAM
[16:22] <Fatal_Sushi> 2 gigs of RAM and a 64-bit processor
[16:23] <Fatal_Sushi> 10GB diskspace iirc
[16:23] <Fatal_Sushi> as of 20.04
 Nonono
 1gb is enough for sure (re @lubuntu_bot: (irc) <Fatal_Sushi> 2 gigs of RAM and a 64-bit processor)
 Seems Lubuntu 21.04 does not boot from CD with 512MB RAM. : https://matterbridge.lubuntu.me/19a1458e/file_3487.jpg
 Ok. I used 20.04 lts (re @Halis: )
 Try 1gb
 I tried with 768MB and it did boot and installer also runs
 I think it's a good idea to post that somewhere
 Maybe a wiki
 For other people not to waste time trying it on 512mb boards
 Downloading now 21.10. Will also test it. Then 768MB could be the "requirement for successful boot"
 Probably RAM usage could be reduced with wayland. Youtubers reported a few hundred MB usage reduced just by switching to wayland on other Ubuntu based distros
[16:44] <Fatal_Sushi> @emergencyrussia those are the minimum system requirements of Lubuntu since 20.04. 32bit isn't supported anymore, 64bit only.
 Ok, ok (re @lubuntu_bot: (irc) <Fatal_Sushi> @emergencyrussia those are the minimum system requirements of Lubuntu since 20.04. 32bit isn't supported anymore, 64bit only.)
 I tried that out of fun
 Is there a something like a board for Lubuntu issues for those who want to try contributing?
 Seems it was 512MB, not 512MiB. I will try again with 512MiB (re @Halis: )
[16:47] <Fatal_Sushi> @emergencyrussia Launchpad is used for reporting issues and bugs
 https://matterbridge.lubuntu.me/650bb41a/file_3488.jpg
[16:50] <Fatal_Sushi> weird they don't mention anything on their site where to report them
[16:50] <Fatal_Sushi> try their forum
[16:51] <Zer0> HIii
 https://phab.lubuntu.me/w/bugs/
 Use our wiki link for bugs ^
[16:53] <Fatal_Sushi> thanks @kc2bez
 Sure thing.
 As far as system requirements this blog post should be considered. https://lubuntu.me/taking-a-new-direction/