[06:59] <KombuchaKip> Just to confirm, there is still no way to edit a previous commit log entry (viz. #210142)?
[07:47] <vila> KombuchaKip: confirmed (unless you can uncommit and re-commit)
[07:47] <vila> hi all !
[07:52]  * fullermd vila at waves.
[07:54]  * vila waves back at fullermd and wonders . o O (He cannot be in the same TZ anymore...)
[07:56] <fullermd> Pfui.  TZ's are for the little people.
[08:12] <didrocks> vila: hey, how are you?
[08:12] <vila> didrocks: fine, thanks, may I help ?
[08:13] <didrocks> vila: I guess you may, yes!
[08:13] <vila> good, consider yourself helped
[08:13] <didrocks> vila: the tarmac merger for unity is blocking on a bzr traceback
[08:13] <vila> :)
[08:13] <didrocks> :p
[08:13] <vila> care to pastebin it ?
[08:13] <vila> !paste
[08:13] <didrocks> vila: http://paste.ubuntu.com/855099/
[08:14] <didrocks> vila: hey, how are you? the first time I encounter that
[08:14] <didrocks> vila: I guess you need the offending branch!
[08:15] <didrocks> vila: I think it's tarmac at the end using an empty --author or something like that?
[08:15] <vila> well, this looks like a tarmac traceback, a '\n' in an author looks indeed wrong
[08:15] <didrocks> vila: so basically, that would mean tarmac try to bzr commit --author "foo\n" ?
[08:16] <didrocks> (just need to know where to start to look at)
[08:16] <vila> from the traceback, yes
[08:17] <didrocks> ok, that's all I needed to know!
[08:17] <didrocks> thanks vila :)
[08:17] <vila> you're welcome ;)
[08:45] <didrocks> vila: ok, found it
[08:46] <didrocks> vila: apparently rev.get_apparent_authors() in bzrlib can returns some \n
[08:46] <didrocks> there was this code in tarmac:
[08:46] <vila> 8-/
[08:46] <didrocks> apparent_authors = rev.get_apparent_authors()
[08:46] <didrocks>                 for author in apparent_authors:
[08:46] <didrocks>                     author.replace('\n', '')
[08:46] <didrocks> the last line, to workaround the issue, should be: author = author.replace('\n', '')
[08:59] <mgz> morning all!
[09:08] <vila> hi mgz
[09:08] <vila> didrocks: nice catch
[09:09] <didrocks> vila: I'm wonering why rev.get_apparent_authors() gives authorname with \n (as it's about merging already existing commits)
[09:09] <vila> didrocks: still worth a bug against bzr IMHO, either we should accept (and filter) '\n' or we shouldn't output them
[09:09] <didrocks> wondering*
[09:09] <didrocks> vila: agreed
[09:09] <didrocks> vila: will open one
[09:09] <vila> thanks
[09:09] <didrocks> vila: and I have a branch with this! :)
[09:10] <didrocks> (as an example)
[09:10] <vila> a bzr one or a tarmac one ?
[09:10] <didrocks> bzr one
[09:10] <vila> oh, as a bug reproducing one :)
[09:10] <didrocks> lucky you, isn't it? :-)
[09:10] <vila> yeah, great !
[09:10] <didrocks> will open it shortly
[11:23] <vila> 2.5.0 frozen, build installers and packages !
[11:24] <fullermd> Sos, that's more than 10 million files later on lplibrarian.
[11:26] <fullermd> Hm.  Y'know that tarball is more than 2 meg bigger than 2.4.2?  Is that right?
[11:26] <jelmer> fullermd: what has changed?
[11:29] <fullermd> Hm.  Well, all the stuff in po/ is new, and that's over 8 meg before compression.  I guess that's it.
[11:29] <jelmer> ah, yep
[11:30] <fullermd> It's really hard to find a current bzrtools from the LP page   :|
[11:30] <fullermd> The series and download link say the latest is 2.3.0, which I know isn't true.  But I always have to dig around for a while before finding the current.
[11:41] <fullermd> Hm.  The build process gives a 'some compiled extensions could not be loaded' error at the end every time.  Doesn't once installed though.  .bzr.log doesn't say anthing about what failed.
[11:41] <fullermd> I don't remember seeing that before.  Is that just some new quirk of the build process?
[11:55] <vila> fullermd: translations ?
[11:56] <vila> (was for the 2m, yeah, you noticed)
[11:57] <vila> hmm, 'some extensions could not be loaded' rings no bells, on the other hand, I'm not sure I start from scratch often enough to have encountered it
[11:58] <vila> fullermd: did the warning also appear in .bzr.log and if yes for which command ?
[11:58] <fullermd> Happens every time I ./setup.py build.
[11:58] <fullermd> (even when there's nothing new to do)
[11:58] <fullermd> It does, but it doesn't say anything about it.
[11:58] <fullermd> Fri 2012-02-24 05:58:40 -0600
[11:58] <fullermd> [25588] 2012-02-24 05:58:41.025 WARNING: bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
[11:58] <fullermd> That's the full extent of it.
[11:58] <vila> meh
[11:59] <vila> test leak ?
[11:59] <fullermd> Doubt it.  build doesn't run the test suite.
[11:59] <fullermd> It's right at the end of the output
[11:59] <fullermd> [...]
[11:59] <fullermd> running build_mo
[11:59] <fullermd> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
[11:59] <fullermd> Does it not do that for you?
[11:59]  * vila tries to reproduce in a clean env
[12:00] <vila> ha, got it
[12:01] <vila> right, so, no command probably hints that it's a direct bzrlib use, I'd bet for some translation script which do not care about extensions
[12:03] <vila> ./tools/generate_docs.py man, bingo
[12:03] <vila> fullermd: so, harmless
[12:04] <vila> uselessly annoying though
[12:05] <vila> fullermd: can be worked around by running make first
[12:11] <fullermd> I figured.  So I recklessly sent the update in anyway.
[12:11] <vila> hehe
[12:12] <vila> thanks for your attention to details *anyway* ;-p
[12:12] <fullermd> Hey, nit-picking stuff that doesn't really matter is my middle name.
[12:13] <fullermd> (makes filling out forms a PITA, true, but otherwise it's kinda fun)
[12:14] <vila> ooooh, 'd' for Details, got it ;)
[12:14] <fullermd> Well, *I* would pick the d for Details.
[12:15] <vila> Where is my milk ? Why is it too cold ? Kind of remarks ?
[12:16] <fullermd> Dad?!
[12:16]  * vila rewinds the tape to listen again...
[12:19] <vila> jelmer: sphinx is already a hard dependency in debian/ubuntu ?
[12:19] <jelmer> vila: no, but it will be used if present
[12:19] <jelmer> vila: I'd either have to add a "Build-Conflicts: python-sphinx" or a patch to disable the sphinx tests
[12:20] <jelmer> I'm a bit wary of doing the first because it means everybody who wants to build the bzr debian package has to uninstall sphinx first
[12:20] <vila> ha, right, so a packager trying to build locally may encounter the issue, sorry, missed that
[12:21] <vila> yup, go for disabling the tests, I think the longer term fix will be to use the provided texinfo builder and only resort to ours for the older sphinx versions (including tests)
[12:21] <fullermd> Oh, crud.  I missed the .mo files...
[12:21] <vila> fullermd: not a big deal for 2.5.0 I think
[12:21] <fullermd> I mean in the package plist.  It is a deal   :p
[12:21] <vila> fullermd: we'll see how it goes for 2.5.1
[12:22] <vila> fullermd: up to you, what I meant is that translations are just starting so most of the strings will still appear in english anyway
[12:23] <vila> fullermd: of course if not carrying the .no files breaks bzr usage, it's a bigger deal ;)
[12:23] <fullermd> No, other way around.
[12:23] <fullermd> They're installed, but without them in the plist they don't get removed on uninstall.
[12:24] <vila> ouch
[12:26] <fullermd> Yeah, that's what I'll be feeling when somebody notices   :p
[12:26]  * fullermd tries to quickly sneak in the change before anybody notices the PR...
[12:30] <fullermd> Well, that takes some of the fun out of updating.  Used to be, I could just look at $PYTHON_SITELIB/bzrlib and know I'd caught 'em all.
[12:32] <vila> :)
[12:41] <jelmer> vila: I'm getting a bunch of test failures in bzrlib.tests.test_btree
[12:41] <jelmer> vila: we haven't changed any of that code recently, have we?
[12:42] <jelmer> http://pastebin.ubuntu.com/855321/
[12:42] <vila> rings no bell
[12:42]  * vila looks
[12:43]  * vila looks again
[12:43] <vila> wth ?
[12:43] <vila> jelmer: during a build ?
[12:44] <jelmer> vila: yes
[12:44] <jelmer> build of 2.5.0
[12:44] <vila> jelmer: do you know the last successful build to narrow the search ?
[12:45] <vila> my first suspicion will be around extensions but we didn't change anything there either AFAIR
[12:45] <jelmer> vila: let me see if it's spurious first
[12:46] <vila> even spurious will be worrying there :-/
[12:46] <jelmer> yeah, I agree
[13:23] <vila> jelmer: any news of these failures ?
[13:24] <jelmer> vila: yep
[13:24] <jelmer> vila: it's reproducible
[13:24] <jelmer> but I can only reproduce it on sid, not on precise
[13:25] <vila> wow, kind of rules out bzr itself no ?
[13:25] <vila> cpython ? pyrex ?
[13:26] <jelmer> vila: It seems hard to speculate about that at this point.
[13:26] <jelmer> vila: cython
[13:28] <vila> oh no, I left a pdb.set_trace() in bzrlib/doc_generate/builders/texinfo.py and it found its way into the tar.gz :-(
[13:29] <mgz> whoops
[13:31] <jelmer> vila: hmm, I don't see a significant difference in the cython and python versions on si and precise
[13:31] <vila> hmm, so, I can think of only two cases where this will trigger: 1) trying to use the texinfo builder (no big deal, even where we use sphinx we don't use the texinfo builder) 2) When running the full test suite where sphinx is installed which is already a filed bug
[13:32] <vila> jelmer: and between the generated C files between <last-known-working> and 2.5.0 ?
[13:33] <vila> but may be the extensions idea is a red herring, I can't reproduce so I'm guessing wildly I can be completely off
[13:34] <vila> jelmer, mgz: I'll remove the offending pdb.set_trace() from the 2.5 *branch*, that will need to be merged on trunk
[13:34] <vila> jelmer, mgz: it also demonstrates that pqm doesn't care :-}
[13:38] <vila> jelmer: even if you disable the texinfo tests, you may want to get rid of the pdb too, just in case (and sorry again about that)
[13:38] <vila> I don't think it's worth releasing 2.5.1 just for that
[13:45] <jelmer> let's see what the cause is of this btree test failure, too
[13:47] <vila> jelmer: yup, 2.5.0 won't be released next week anyway (only the week after) but it would be good to fix the failure before pushing to debian/ubuntu in the mean time
[13:55] <vila> looking at bzr diff -r bzr-2.5b5..6478 ( to avoid the .mo noise) reveals nothing regarding indices, did you try reproducing with 2.5b1 or something like that ?
[13:57] <jelmer> vila: up to 2.5b5 everything built fine in sid
[13:57] <jelmer> perhaps I can try rebuilding 2.5b5, maybe something in sid has changed
[13:57] <vila> yup, that was my suggestion
[13:57] <vila> good to know 2.5b5 built well though
[14:23] <vila> EOD'ing, EOW'ing, have fun guys !
[15:29] <mgz> heh, needless outrage on the mailing list followed immediately by a whoops sorry message
[15:40] <jelmer> :)
[15:50]  * jelmer is still stumped by the test failure
[15:52] <mgz> go artur/me takes a look
[15:52] <mgz> ...at the test failure
[15:53] <mgz> ...the btree ones from the pastebin up there right?
[15:54] <mgz> looks like a cython type issue on a 64 bit build?
[15:55] <jelmer> perhaps
[15:55] <jelmer> but why is it only happening on recent snapshots of debian sid and not on precise?
[15:56] <mgz> what's the exact machine those failures are from?
[15:56] <mgz> and the cython version?
[15:56] <jelmer> chroot on my desktop machine
[15:56] <jelmer> a sid chroot on my desktop machine (x86_64)
[15:56] <mgz> your desktop is... amd64?
[16:00] <mgz> hm... some of the failures make that look less likely
[16:00]  * mgz double checks the put_file implementation
[16:04] <mgz> jelmer: well, osutils.pumpfile is technically borked
[16:04] <mgz> but I'm not sure if fixing that will help you?
[16:05] <mgz> hack the tests to get an actual byte diff output perhaps?
[16:06] <mgz> or I can patch either atomicfile or osutils to be completely correct
[16:07] <jelmer> mgz: hmm
[16:07] <jelmer> I do vaguely recall we changed something in pumpfile - do you remember?
[16:08] <mgz> well, the most apparent problem seems to be this in atomicfile:
[16:08] <mgz>     def write(self, data):
[16:08] <mgz>         """Write some data to the file. Like file.write()"""
[16:08] <mgz>         os.write(self._fd, data)
[16:08] <mgz> that's not like file.write at all, doesn't handle short writes or interrupts
[16:08] <mgz> why you'd be hitting it when no one else has though I do not know.
[16:09] <jelmer> some recent python change in sid perhaps
[16:10] <mgz> anyway, easy enough to turn into a loop and see if it affects the failures
[16:11] <mgz> see osutils.send_all for an approximate template
[16:13] <mgz> if not, we really need to know which bytes are actually missing, rather than just that the expected count is too low
[16:14] <jelmer> I'm not sure if I have enough time to debug it just now, so I think I might just file a bug about it for now.
[16:14] <mgz> if I wave a patch at you, can you apply and see if it changes things?
[16:14] <jelmer> mgz: sure
[16:15] <mgz> okay, sec
[16:15] <mgz> oh, and are the failures completely reliable and unchanging, did you notice?
[16:16] <mgz> would suggest this theory is wrong.
[16:17] <jelmer> mgz: yes, they seem to be consistent
[16:18]  * jelmer was wondering if perhaps it was a \r\n<->\n issue
[16:18] <mgz> yeah, me too, but I don't see how we'd get that on nix and not windows
[16:22] <mgz> okay, rebuilding extensions, apart from the 64bitness this box should be setup similarly to yours
[16:24] <mgz> and I have the failure
[16:24] <mgz> ace.
[16:24] <jelmer> ah, good
[16:26] <mgz> hm, I also get this:
[16:26] <mgz> failed to load compiled extension: .../bzrlib/_static_tuple_c.so: undefined symbol: __Pyx_PyIdentifier_FromString
[16:27]  * mgz does make realclean to be sure
[16:30] <mgz> still there, will deal with later
[16:55] <mgz> jelmer: okay, new theory
[16:56] <mgz> we've got an updated zlib that compresses very slightly better
[16:57] <jelmer> I guess that's possible
[16:57] <jelmer> let me try installing the sid one on precise and see if that breaks things
[17:05] <jelmer> mgz: yes, that's it
[17:06]  * jelmer files a bug
[21:50] <dOxxx> howdy
[21:51] <dOxxx> so the whole ssl cacert thing... any idea how I would go about test it?
[22:21] <wgz> dOxxx: just giving a https url as a branch location is okay for starts
[22:22] <wgz> vila had a test site that had some extra things like self signed certs but I can't find it right now
[22:22] <dOxxx> wgz: can you give an example URL from like launchpad?
[22:25] <wgz> `bzr info https://bazaar.launchpad.net/notabranch` for instace
[22:26] <dOxxx> aha, I see. thanks.
[22:26] <dOxxx> of course now if I could get sphinx to work, maybe I could get somewhere..... ;_;
[22:27] <wgz> have you seen the log from earlier today?
[22:27] <dOxxx> no?
[22:27] <wgz> vila had some sphinxy points
[22:27] <dOxxx> for me, it just breaks into pdb when sphinx is invoked by the bzr build
[22:29] <wgz> http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t11:23
[22:29] <wgz> yeah, he realised after making the tarball
[22:29] <wgz> http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t13:28
[22:30] <dOxxx> hmmm
[22:30] <dOxxx> so I have to run `./tools/generate_docs.py man` before the main bzr setup.py?
[22:32] <wgz> whatever works to get you past that
[22:32] <dOxxx> eugh no the pdb thing is something else
[22:33] <dOxxx> *sigh*
[22:33] <dOxxx> it's the second thing you linked
[22:35] <dOxxx> vila makes my life hard :P
[22:36] <wgz> you certainly deserve a small piece of cake when you're done
[22:40] <dOxxx> wgz: sorry to bother you, but you're the only one around :)
[22:41] <dOxxx> wgz: any idea what the error 'Builder 'texinfo' is a builtin builder' means from sphinx?
[22:42] <wgz> I'm happy to be bothered :)
[22:42] <wgz> that's the thing talked about in the log right?
[22:43] <wgz> bzr registers its own texinfo builder for sphinx,
[22:43] <wgz> but the newer version of sphinx has added one to the builders it provides builtin
[22:44] <dOxxx> yeah so it would appear
[22:44] <wgz> I agree it's not clear what the right short term fix is
[22:44] <wgz> you should be able to run the build process without generating the tex stuff from what I gather?
[22:44] <dOxxx> maybe I should try reverting to an older version of sphinx
[22:45] <dOxxx> well then I don't get documentation...
[22:45] <wgz> that's all that seems to be suggested, beyond "try and see at some point in the future if the builtin one will work for us"
[22:45] <dOxxx> I'm building the OS x installer, so I need to include docs
[22:45] <wgz> ...ah, and you depend on that rather than the html?
[22:46] <dOxxx> so it's only the pdf?
[22:46] <dOxxx> that causes this problem
[22:46]  * wgz hasn't looked at your process in detail yet, I just crib from your nice list of plugin versions when doing windows installers
[22:46] <dOxxx> I build both html and pdf, so users have a choice of which they prefer
[22:46] <dOxxx> heh
[22:47] <wgz> that seems possible
[22:47] <dOxxx> since pdf is pretty well supported on os x
[22:47] <wgz> trying a sphinx downgrade seems sensible
[22:47] <wgz> as I agree osxy people likely expect pdf
[22:47] <wgz> okay, I've got to eat something, but am around, so keep throwing questions in here as you need
[22:48] <dOxxx> thanks!
[22:50] <dOxxx> halleluja! downgrading to 1.0 seems to have worked
[22:50] <dOxxx> I spoke too soon
[22:56] <dOxxx> wgz: so using sphinx 1.0 crashes with some other error and just running 'make html-sphinx' still gives the texinfo is a builtin error
[22:56] <dOxxx> is there any alternate way of building the html docs?
[22:58] <dOxxx> ah, 'make html-docs'
[23:26] <wgz> so, the smart thing for this release is just to not do the pdf docs?
[23:26] <wgz> would be nice if sphinx were a little less... volatile
[23:31] <dOxxx> wgz: I'm doing a build with just html docs but I'm going to have to rework the packager layout as well since it's expecting pdf docs
[23:32] <dOxxx> hmm actually no
[23:32] <dOxxx> the packager doesn't install the docs
[23:32] <dOxxx> I leave them in the disk image
[23:32] <dOxxx> so maybe this won't be so bad...
[23:34] <wgz> well, would be nice if one thing at least was simpler than expected this evening
[23:34] <fullermd> As long as that's happening, can I have a pony too?
[23:35] <wgz> certainly, as long as it doesn't need sphinx to build
[23:36] <dOxxx> one last thing to try to get sphinx working....
[23:37] <fullermd> Sweet.  I shall name him Gumdrops, and he will follow me everywhere and bite people who cut me off in traffic.
[23:38] <dOxxx> afk dinner while my build crash & burns


[00:05] -queuebot:#ubuntu-release- New binary: pbcopper [riscv64] (noble-proposed/universe) [2.3.0+dfsg-2] (no packageset)
[03:10] <tsimonq2> xnox: FYI say hi to r/Ubuntu where https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/comments/48 is linked.
[03:10] -ubottu:#ubuntu-release- Launchpad bug 2044657 in zfs-linux (Ubuntu Jammy) "Multiple data corruption issues in zfs" [High, Confirmed]
[05:24] -queuebot:#ubuntu-release- New binary: gnome-snapshot [amd64] (noble-proposed/none) [45.2-2] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: gnome-snapshot [ppc64el] (noble-proposed/none) [45.2-2] (no packageset)
[05:26] -queuebot:#ubuntu-release- New binary: gnome-snapshot [s390x] (noble-proposed/none) [45.2-2] (no packageset)
[05:48] -queuebot:#ubuntu-release- New binary: gnome-snapshot [armhf] (noble-proposed/universe) [45.2-2] (no packageset)
[05:53] -queuebot:#ubuntu-release- New binary: gnome-snapshot [arm64] (noble-proposed/universe) [45.2-2] (no packageset)
[07:04] -queuebot:#ubuntu-release- New binary: gnome-snapshot [riscv64] (noble-proposed/universe) [45.2-2] (no packageset)
[09:05] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [amd64] (noble-proposed) [45.2-2]
[09:05] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [armhf] (noble-proposed) [45.2-2]
[09:06] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [riscv64] (noble-proposed) [45.2-2]
[09:06] -queuebot:#ubuntu-release- New: accepted gpu-burn [amd64] (noble-proposed) [0+git20240115+ds-1]
[09:06] -queuebot:#ubuntu-release- New: accepted pbcopper [arm64] (noble-proposed) [2.3.0+dfsg-2]
[09:06] -queuebot:#ubuntu-release- New: accepted pbcopper [riscv64] (noble-proposed) [2.3.0+dfsg-2]
[09:06] -queuebot:#ubuntu-release- New: accepted rustc [arm64] (noble-proposed) [1.75.0+dfsg0ubuntu1-0ubuntu1]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [arm64] (noble-proposed) [2.1.6-1]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [ppc64el] (noble-proposed) [2.1.6-1]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [s390x] (noble-proposed) [2.1.6-1]
[09:06] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [arm64] (noble-proposed) [45.2-2]
[09:06] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [s390x] (noble-proposed) [45.2-2]
[09:06] -queuebot:#ubuntu-release- New: accepted pbcopper [ppc64el] (noble-proposed) [2.3.0+dfsg-2]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [amd64] (noble-proposed) [2.1.6-1]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [riscv64] (noble-proposed) [2.1.6-1]
[09:06] -queuebot:#ubuntu-release- New: accepted gnome-snapshot [ppc64el] (noble-proposed) [45.2-2]
[09:06] -queuebot:#ubuntu-release- New: accepted pbcopper [s390x] (noble-proposed) [2.3.0+dfsg-2]
[09:06] -queuebot:#ubuntu-release- New: accepted pbcopper [amd64] (noble-proposed) [2.3.0+dfsg-2]
[09:06] -queuebot:#ubuntu-release- New: accepted srcpd [armhf] (noble-proposed) [2.1.6-1]
[10:32] -queuebot:#ubuntu-release- New source: cadabra2 (noble-proposed/primary) [<IP_ADDRESS>-0ubuntu1]
[10:34] -queuebot:#ubuntu-release- New: accepted cadabra2 [source] (noble-proposed) [<IP_ADDRESS>-0ubuntu1]
[10:42] -queuebot:#ubuntu-release- New binary: cadabra2 [amd64] (noble-proposed/none) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[10:44] -queuebot:#ubuntu-release- New binary: cadabra2 [s390x] (noble-proposed/none) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[10:45] -queuebot:#ubuntu-release- New binary: cadabra2 [arm64] (noble-proposed/none) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[10:45] -queuebot:#ubuntu-release- New binary: cadabra2 [ppc64el] (noble-proposed/none) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[10:46] -queuebot:#ubuntu-release- New: accepted cadabra2 [amd64] (noble-proposed) [<IP_ADDRESS>-0ubuntu1]
[10:46] -queuebot:#ubuntu-release- New: accepted cadabra2 [ppc64el] (noble-proposed) [<IP_ADDRESS>-0ubuntu1]
[10:46] -queuebot:#ubuntu-release- New: accepted cadabra2 [arm64] (noble-proposed) [<IP_ADDRESS>-0ubuntu1]
[10:46] -queuebot:#ubuntu-release- New: accepted cadabra2 [s390x] (noble-proposed) [<IP_ADDRESS>-0ubuntu1]
[11:30] -queuebot:#ubuntu-release- New binary: gcc-defaults [armhf] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:34] -queuebot:#ubuntu-release- New binary: gcc-defaults [amd64] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:35] -queuebot:#ubuntu-release- New binary: gcc-defaults [arm64] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:36] -queuebot:#ubuntu-release- New binary: gcc-defaults [i386] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:36] -queuebot:#ubuntu-release- New binary: gcc-defaults [s390x] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [amd64] (noble-proposed) [1.210ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [armhf] (noble-proposed) [1.210ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [s390x] (noble-proposed) [1.210ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [arm64] (noble-proposed) [1.210ubuntu1]
[11:37] -queuebot:#ubuntu-release- New binary: gcc-defaults [ppc64el] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [i386] (noble-proposed) [1.210ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted gcc-defaults [ppc64el] (noble-proposed) [1.210ubuntu1]
[11:54] -queuebot:#ubuntu-release- New binary: gcc-defaults [riscv64] (noble-proposed/main) [1.210ubuntu1] (core, i386-whitelist)
[11:54] -queuebot:#ubuntu-release- New: accepted gcc-defaults [riscv64] (noble-proposed) [1.210ubuntu1]
[12:04] -queuebot:#ubuntu-release- Unapproved: cinder (mantic-proposed/main) [2:23.0.0-0ubuntu1 => 2:23.0.0-0ubuntu1.1] (openstack)
[13:02] <tjaalton> LocutusOfBorg: why are you reusing the same bug for vbox sru?
[13:02] <tjaalton> lp2017101
[13:02] <tjaalton> lp#2017101
[13:02] -ubottu:#ubuntu-release- Launchpad bug 2017101 in virtualbox-hwe (Ubuntu Mantic) "[SRU] Virtualbox 7.0.12 and 6.1.48" [Undecided, Fix Released] https://launchpad.net/bugs/2017101
[13:10] <tjaalton> seems you've filed a new bug but forgot to use it
[13:11] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (mantic-proposed) [7.0.14-dfsg-1~ubuntu<IP_ADDRESS>]
[13:14] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (mantic-proposed) [7.0.14-dfsg-1~ubuntu<IP_ADDRESS>]
[13:15] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-guest-additions-iso [source] (mantic-proposed) [7.0.14-1~ubuntu<IP_ADDRESS>]
[13:22] <LocutusOfBorg> tjaalton, more like I did wrong copy-paste
[13:22] <LocutusOfBorg> daaaaaaaaaaaaamn
[13:22] <LocutusOfBorg> and I triple checked it
[13:22] <LocutusOfBorg> :(
[13:32] <tjaalton> I'll just reject them all without looking each one
[13:33] <tjaalton> oh wait
[13:33] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-ext-pack [source] (mantic-proposed) [7.0.14-1~ubuntu<IP_ADDRESS>]
[13:33] <tjaalton> jammy might be good
[13:33] <tjaalton> mantic wasnt
[13:35] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (jammy-proposed) [6.1.50-1~ubuntu<IP_ADDRESS>]
[13:37] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (jammy-proposed) [6.1.50-dfsg-1~ubuntu<IP_ADDRESS>]
[13:43] <tjaalton> LocutusOfBorg: so jammy at least is fine so far, just mantic needs fixing I guess
[13:46] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (jammy-proposed) [6.1.50-dfsg-1~ubuntu<IP_ADDRESS>]
[13:47] <tjaalton> focal is fine too
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (jammy-proposed) [6.1.50-1~ubuntu<IP_ADDRESS>]
[13:48] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (focal-proposed) [6.1.50-1~ubuntu<IP_ADDRESS>]
[13:49] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.50-dfsg-1~ubuntu<IP_ADDRESS>]
[13:49] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (focal-proposed) [6.1.50-dfsg-1~ubuntu<IP_ADDRESS>]
[13:50] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (focal-proposed) [6.1.50-1~ubuntu<IP_ADDRESS>]
[13:57] <LocutusOfBorg> tjaalton, thanks
[13:57] <LocutusOfBorg> will reupload now
[13:58] -queuebot:#ubuntu-release- Unapproved: accepted fsvs [source] (mantic-proposed) [1.2.9-2ubuntu<IP_ADDRESS>]
[13:59] -queuebot:#ubuntu-release- Unapproved: accepted fsvs [source] (jammy-proposed) [1.2.9-2ubuntu<IP_ADDRESS>]
[14:00] -queuebot:#ubuntu-release- Unapproved: accepted fsvs [source] (focal-proposed) [1.2.7-1ubuntu0.1]
[14:13] <tjaalton> bryceh: hi! I'm looking at open-vm-tools, but noticed that it has "debian/changelog.dch" on it which seems to be extra cruft?
[14:14] <tjaalton> basically a dupe of d/changelog plus some ppa upload on top
[14:16] <tjaalton> that's the mantic upload
[14:16] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (jammy-proposed) [1:22.04.19]
[14:16] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.18 => 1:22.04.19] (core)
[14:24] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (focal-proposed) [1:<IP_ADDRESS>]
[14:32] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[14:32] <bryceh> tjaalton, yes that's just cruft, sorry
[14:32] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (bionic-proposed) [1:<IP_ADDRESS>]
[14:33] <bryceh> tjaalton, want me to respin and reupload?
[14:38] -queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[14:39] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (xenial-proposed) [1:16.04.20]
[14:40] <tjaalton> bryceh: yeah that'd be nice, thanks
[14:42] -queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (mantic-proposed) [2:12.3.5-3~ubuntu<IP_ADDRESS>]
[14:54] <bryceh> tjaalton, fix mantic pkg uploaded
[14:55] <bryceh> bbiab
[14:56] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (mantic-proposed/main) [2:12.3.0-1ubuntu0.1 => 2:12.3.5-3~ubuntu<IP_ADDRESS>] (ubuntu-cloud, ubuntu-desktop, ubuntu-server)
[14:57] <tjaalton> bryceh: thanks, looking
[15:22] <philroche> \o How do meta packages work when uploaded to noble -proposed? I see a new ubuntu-server package has been uploaded today and is in -proposed but I don't see any autopkgtests that would gate its promotion to -release @ https://autopkgtest.ubuntu.com/packages/ubuntu-server
[15:24] <bdmurray> philroche: the tests could still be queued
[15:24] <rbasak> philroche: it should just migrate once fully built and published. Unless there's something blocking it.
[15:24] <bdmurray> philroche: oh, the package has not tests
[15:24] <rbasak> On the last run riscv64 wasn't built yet. Apparently it is now.
[15:25] <philroche> Ah - I see it in https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html
[15:29] <philroche> So just a matter of waiting until the fact that riscv64 has been published is registered and it will auto migrate to -release?
[15:30] <rbasak> Yes, unless the excuses page flags something else
[15:30] <philroche> +1
[15:39] -queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.19 => 1:16.04.20] (core)
[15:58] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (mantic-proposed/multiverse) [7.0.12-2~ubuntu<IP_ADDRESS> => 7.0.14-1~ubuntu<IP_ADDRESS>] (no packageset)
[15:59] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (mantic-proposed/multiverse) [7.0.12-1~ubuntu<IP_ADDRESS> => 7.0.14-1~ubuntu<IP_ADDRESS>] (no packageset)
[16:00] <LocutusOfBorg> tjaalton, ^^ please?
[16:01] -queuebot:#ubuntu-release- Unapproved: virtualbox (mantic-proposed/multiverse) [7.0.12-dfsg-1~ubuntu<IP_ADDRESS> => 7.0.14-dfsg-1~ubuntu<IP_ADDRESS>] (kernel-dkms, ubuntu-cloud)
[16:02] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (mantic-proposed/multiverse) [7.0.12-dfsg-1~ubuntu<IP_ADDRESS> => 7.0.14-dfsg-1~ubuntu<IP_ADDRESS>] (kernel-dkms)
[16:03] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (mantic-proposed) [2:12.3.5-3~ubuntu<IP_ADDRESS>]
[16:05] -queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (jammy-proposed) [2:12.3.5-3~ubuntu<IP_ADDRESS>]
[16:05] <tjaalton> LocutusOfBorg: ack, waiting for the diff
[16:06] <LocutusOfBorg> ack thanks
[16:07] <LocutusOfBorg> arraybolt3, ^^ help testing pleeeeeeease?
[16:07] <arraybolt3> LocutusOfBorg: Sure thing :)
[16:07] <arraybolt3> Still got all my ISOs armed and ready for use
[16:08] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (mantic-proposed) [7.0.14-1~ubuntu<IP_ADDRESS>]
[16:09] <LocutusOfBorg> thanks!
[16:10] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (mantic-proposed) [7.0.14-1~ubuntu<IP_ADDRESS>]
[16:11] <tjaalton> LocutusOfBorg: the kbuild bump; jammy doesn't have the newer version
[16:12] <tjaalton> will it fail there?
[16:13] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (mantic-proposed) [7.0.14-dfsg-1~ubuntu<IP_ADDRESS>]
[16:14] <tjaalton> didn't
[16:14] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (mantic-proposed) [7.0.14-dfsg-1~ubuntu<IP_ADDRESS>]
[16:14] <LocutusOfBorg> mmm
[16:14] <LocutusOfBorg> no?
[16:15] <LocutusOfBorg> didn't bump kbuild in 7.0.14
[16:15] <tjaalton> not for jammy
[16:15] <tjaalton> -1 did it for mantic, but it has that
[16:15] <LocutusOfBorg> exactly
[16:16] <LocutusOfBorg> I didn't strip libsdl2 library < 7.0.x
[16:16] <LocutusOfBorg> so we don't need newer kbuild there
[16:17] <tjaalton> ok
[16:17] <tjaalton> I'm done
[16:17] <LocutusOfBorg> thanks!
[16:17] <LocutusOfBorg> I already asked on #vbox-dev for testing, the user reporting issues will probably be happy to confirm the fix
[16:18] <LocutusOfBorg> I'll adjoust my testing based on community feedbacks
[16:27] <arraybolt3> ETA before testing packages hit -proposed?
[16:27] <arraybolt3> want to get as much done as possible while possible
[17:09] <LocutusOfBorg> arraybolt3, focal, jammy should be already there
[17:10] <LocutusOfBorg>  virtualbox | 6.1.50-dfsg-1~ubuntu<IP_ADDRESS>       | focal-proposed/multiverse  | source, amd64
[17:10] <LocutusOfBorg>  virtualbox | 6.1.50-dfsg-1~ubuntu<IP_ADDRESS>       | jammy-proposed/multiverse  | source, amd64
[17:11] <LocutusOfBorg> mantic should be there in one install
[17:23] <arraybolt3> +1
[17:23] -queuebot:#ubuntu-release- New binary: python-djvulibre [amd64] (noble-proposed/none) [0.9.0-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: python-djvulibre [ppc64el] (noble-proposed/none) [0.9.0-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: python-djvulibre [s390x] (noble-proposed/none) [0.9.0-1] (no packageset)
[17:38] -queuebot:#ubuntu-release- New binary: python-djvulibre [arm64] (noble-proposed/universe) [0.9.0-1] (no packageset)
[17:47] -queuebot:#ubuntu-release- New binary: python-djvulibre [armhf] (noble-proposed/universe) [0.9.0-1] (no packageset)
[17:56] <LocutusOfBorg> arraybolt3, looks now in mantic-proposed too
[18:05] <arraybolt3> perfect
[18:59] -queuebot:#ubuntu-release- New binary: python-djvulibre [riscv64] (noble-proposed/universe) [0.9.0-1] (no packageset)
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [amd64] (noble-proposed) [0.9.0-1]
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [armhf] (noble-proposed) [0.9.0-1]
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [riscv64] (noble-proposed) [0.9.0-1]
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [arm64] (noble-proposed) [0.9.0-1]
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [s390x] (noble-proposed) [0.9.0-1]
[19:04] -queuebot:#ubuntu-release- New: accepted python-djvulibre [ppc64el] (noble-proposed) [0.9.0-1]
[19:14] <arraybolt3> LocutusOfBorg: What exactly was expected to potentially break in Win8.1? It seems to work flawlessly here with the new VBox.
[19:15] <arraybolt3> ooooh, except for a 3d acceleration bug
[19:21] <arraybolt3> and Seamless Mode is a bit glitchy
[19:21] -queuebot:#ubuntu-release- Unapproved: google-guest-agent (jammy-security/main) [20231004.02-0ubuntu1~22.04.2 => 20220622.00-0ubuntu2~22.04.1] (core) (sync)
[19:21] <arraybolt3> but neither of those are big deals I don't think, I'll check the older version of VBox just to make sure it's not a regressoin
[19:21] -queuebot:#ubuntu-release- Unapproved: google-guest-agent (focal-security/universe) [20231004.02-0ubuntu1~20.04.2 => 20220622.00-0ubuntu2~20.04.2] (no packageset) (sync)
[19:23] -queuebot:#ubuntu-release- Unapproved: accepted google-guest-agent [sync] (jammy-security) [20220622.00-0ubuntu2~22.04.1]
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted google-guest-agent [sync] (focal-security) [20220622.00-0ubuntu2~20.04.2]
[20:48] <tsimonq2> bdmurray: https://discourse.ubuntu.com/t/24-04-feature-freeze-and-transitions/41948 :)
[21:02] <jbicha> tsimonq2: the armhf 32-bit time transition is a big one that will happen soon
[22:13] <tsimonq2> jbicha: I wasn't remembering if that was included with the glibc update or not, mind throwing something on the thread when you get the chance? :)
[22:15] <jbicha> well I don't have a timeline for it, but there's been a lot of discussion on the debian-devel list and it has to happen soon for 24.04 LTS because too many usecases will have Y2038 issues otherwise before support ends
[22:16] <tsimonq2> I've been wondering... 24 + 12 = 36, which means there's still a two year gap for ESM, am I missing something? :)
[22:17] <jbicha> think if you want to put something on your calendar for 2 years in the future, or imagine security certificates that are valid for 3 years, 5 years, 10 years
[22:19] <tsimonq2> Ah, okay. That would make sense
[22:20] <tsimonq2> Thanks! Curious to hear from Foundations :)
[23:18] -queuebot:#ubuntu-release- New binary: asterisk-espeak [amd64] (noble-proposed/universe) [5.0~1-4] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: asterisk-espeak [s390x] (noble-proposed/universe) [5.0~1-4] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: asterisk-espeak [armhf] (noble-proposed/universe) [5.0~1-4] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: asterisk-espeak [arm64] (noble-proposed/universe) [5.0~1-4] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: gensio [amd64] (noble-proposed/universe) [2.8.2-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: asterisk-espeak [ppc64el] (noble-proposed/universe) [5.0~1-4] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: pointpats [amd64] (noble-proposed/universe) [2.4.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: gensio [s390x] (noble-proposed/universe) [2.8.2-1] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: asterisk-espeak [riscv64] (noble-proposed/universe) [5.0~1-4] (no packageset)


[12:03] <Darwin> According to Wikipedia, the Feisty Release Candidate is released today
[12:03] <cyberkun> alright
[12:03] <gnomefreak> cyberkun: wait
[12:03] <cyberkun> wait
[12:04] <cyberkun> k
[12:04] <shooters> cyberkun: can you pastebin the entire output?
[12:04] <macd> Darwin, read the topic, the RC will be released on the week of the 19th.
[12:04] <gnomefreak> cyberkun: wait first run sudo apt-get dist-upgrade if you did that please run sudo dpkg --configure -a
[12:04] <macd> UNDERsoN, same ^^
[12:04] <gnomefreak> macd: re read it it doesnt say that
[12:05] <gnomefreak> it says the release date is week of 19th
[12:05] <aubade> I'm lost, 20070412 was rejected so 20070411 is the RC?
[12:05] <cyberkun> !pastebin
[12:05] <cyberkun> wait
[12:05] <cyberkun> thats not it
[12:05] <gnomefreak> aubade: no rc yet
[12:05] <aubade> gnomefreak: Ah, alright.
[12:05] <macd> gnomefreak, Im not sure how I didnt say the week of the 19th.
[12:05] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[12:05] <gnomefreak> arejay: rc will be released in a few days
[12:06] <Darwin> macd, I know but I've read some conflicting info online so I want to make sure
[12:06] <macd> nvm, rc not week of.....
[12:06] <gnomefreak> macd: you said rc will be released week of 19th
[12:06] <macd> yeah ;)
[12:06] <cyberkun> http://paste.ubuntu-nl.org/15282/
[12:06] <UNDERsoN> week 19th  is release not RC
[12:06] <cyberkun> thats after the install
[12:06] <gnomefreak> it should be fixed and out this weekend we hope
[12:06] <macd> nasty kernel bug
[12:07] <aubade> So 20070411 is just a candidate for the release candidate? Oh, if ever there was something to say five times fast.
[12:07] <shooters> cyberkun: try 'sudo apt-get dist-upgrade'
[12:07] <gnomefreak> its ati/kernel
[12:07] <Darwin> so when is the RC released?
[12:08] <zdzichuBG> there are like over 200 nasty kernel bugs :/
[12:08] <cyberkun> there we go agian
[12:08] <gnomefreak> Darwin: noone knows yet
[12:08] <aubade> The projected date was today, apparently it'll be out in the next few days.
[12:08] <cyberkun> lots of files are downloaded
[12:08] <cyberkun> ing
[12:08] <shooters> cyberkun: all 248 packages?
[12:08] <cyberkun> 248 upgraded, 108 newly installed, 3 to remove and 0 not upgraded.
[12:08] <cyberkun> Need to get 5761kB/342MB of archives.
[12:08] <cyberkun> After unpacking 360MB of additional disk space will be used.
[12:08] <cyberkun> Do you want to continue [Y/n] ? y
[12:08] <gnomefreak> upgrade doesnt get everything
[12:08] <cyberkun> Get:1 http://us.archive.ubuntu.com feisty/main libpanel-applet2-0 1:2.18.1-0ubuntu3 [103kB]
[12:09] <gnomefreak> cyberkun: ok dont paste
[12:09] <cyberkun> yea I noticed
[12:09] <cyberkun> It is too big
[12:09] <Darwin> gnomefreak, thanks for clearing that up
[12:09] <cyberkun> I wanted to remove a few lines but they got sent beforehand
[12:09] <cypherdelic> Can somebody help me with nvidia-glx-new
[12:09] <cypherdelic> ??
[12:10] <gnomefreak> cyberkun: what about it?
[12:10] <cypherdelic> cypherdelic@HaeckFlaisch:~$ glxinfo
[12:10] <cypherdelic> name of display: :1.0
[12:10] <cypherdelic> display: :1  screen: 0
[12:10] <cypherdelic> direct rendering: No
[12:10] <TheSilentW> how do i outdate my java runtimes (JRE ?) cause aptana is really show, i read something about it at school but i dont remember :(
[12:10] <gnomefreak> cyberkun: what card do you have?
[12:10] <gnomefreak> cypherdelic: what card do you have
[12:10] <cypherdelic> nvidia 7600 go
[12:11] <_Neil> Hey gnomefreak, did you ever figure out that Realplayer bug?
[12:11] <cyberkun> video card? thats not an issue here. It was the fiesty wasnting installing correctly. I belive Shooter got this issue
[12:11] <_Neil> Might have a look at it again tonight.
[12:11] <gnomefreak> _Neil: no i havent had time to look
[12:11] <gnomefreak> cyberkun: it was for someone else auto complete error
[12:11] <_Neil> cool cool, I'll add any progress I make to the bug report
[12:12] <cyberkun> thats what I thought but you said cyberkun first so I count be sure
[12:15] <holle> hi
[12:16] <cyberkun> hello holle
[12:17] <Hairulfr>       hello cyberkun
[12:17] <holle> i have an feisty issue ...it's booting fine with my old edgy kernel/initrd.img, but with the new feisty kernel my system is unable to mount the root fs ("waiting for root filesystem"). I am using  lilo as bootloader on a macbook (sata drive, intel chipset).... i appended root=UUID:myid tolilo
[12:17] <holle> i have no idea what to try next :-(
[12:18] <TheSilentW> anyone know how to let windows freely slide (like when u turn off friction on the wobble settings) but without the atual wobble in beryl?
[12:18] <TheSilentW> wrong channel :(
[12:23] <nomasteryoda> TheSilentW, turn off water?
[12:23] <TheSilentW> dont have water
[12:23] <jamie> any one help the gnome panel has disapeared for the user jamie not any other users. cant get it back any ideas?
[12:24] <nomasteryoda> hmm, let me look
[12:25] <atselby> Can i get help with Feisty desktop effects?
[12:25] <nomasteryoda> under Visual effects, wobbly windows is offi?
[12:25] <TheSilentW> no
[12:25] <nomasteryoda> k
[12:25] <nomasteryoda> what about shiver?
[12:26] <ulmolavender> ah, networkmanager died, I had to reconnect with wlassistant :/
[12:26] <TheSilentW> i turn it on/off and saw no effect
[12:26] <atselby> >>
[12:26] <nomasteryoda> you restart beryl?
[12:26] <TheSilentW> nope
[12:26] <TheSilentW> should i?
[12:26] <nomasteryoda> i've had to do that before
[12:26] <TheSilentW> so...i turn off shiver?
[12:26] <Arwen> that network monitor applet always shows "no connection" for me, anyone else getting taht issue?
[12:27] <nomasteryoda> ya
[12:27] <TheSilentW> can u tell me your settings
[12:27] <TheSilentW> for that wobbly plugin
[12:27] <TheSilentW> i am new to linux and beryl so
[12:27] <TheSilentW> xD
[12:27] <nomasteryoda> hold on
[12:27] <nomasteryoda> np


[19:00] <willwh> hey guys :)
[19:02]  * genii makes more coffee and passes the mugs around
[19:02] <willwh> genii: :)
[19:04] <willwh> am I just being daft?
[19:04] <willwh> crontab -e
[19:04] <willwh> 2 * * * * willwh /home/willwh/bash/player.sh
[19:04] <willwh> I am tailing syslog and I don't see anything
[19:05] <willwh> player.sh is executable (I'm using - logger "some stuff") - when I run it in the term it runs fine and I see my syslog entries
[19:05] <willwh> but no dice with cron
[19:05] <willwh> scratching my head


[03:04] <rainmatter> how can I enable hardware acceleration on Raspberry Pi 4 running Ubuntu 19.10.1 x64?
[03:05] <rainmatter> arm64, sorry


 http://sourceforge.net/projects/xiaopanos/
[05:36] <bazhang> he knows its offtopic, yet acts surprised after he posts it
[09:11] <sveta> fyi i kicked<EMAIL_ADDRESS>(DJ CYBORG) for flooding 0s in #ubuntu but i didn't quiet him as he's not very intent on rejoining
[12:29] <IdleOne> thanks sveta
 it's for UBUNTU
 so it's not OFF_TOPIC
[15:46] <bazhang> "android is LINUX!!11"
[17:15] <genii> Heh
[17:24] <bazhang> * [amafckingfgt] (~yee-va-ta@<IP_ADDRESS>): Yee-Va-Tal
[17:24] <bazhang> that seems to be an unpleasant nick
[17:48] <genii> Must be "pick a nasty nick" day or something.
[17:49] <DJones> That nick (or ones very close to it) have a very poor reputation in #ubuntu
[17:51] <DJones> Racisim & offensive multiple times
[17:54] <DJones> Maybe a ban on *semen*.* is needed
[18:02] <genii> That would eliminate names like horsemen
[18:02] <Pici> and horse_semen
[18:03] <genii> <rolls eyes>
[18:06] <DJones> ok, set an exception for horsemen
[18:06] <Pici> and basemen
[18:10] <DJones> On the upside, /lastlog shows no entries for horsemen or basemen
[18:11] <DJones> I haven;t got logs enough to grep for either of those
[18:12] <Pici> What about disenfranchisement?
[18:22] <DJones> How often has that nick appeared?
[18:23] <Pici> If you can't tell, I'm being facetious
[18:27] <DJones> I can tell, but its a valid point, at the end of the day if somebody with a nick that "contains" something inappropriate they can ask for an exemption for valid reasons