[00:01] <NCommander> I did all that
[00:01] <TheMuso> NCommander: Ok.
[00:01] <NCommander> Very strange
[00:01] <TheMuso> Let me know when its ready to pull.
[00:04] <NCommander> http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary - I pushed it, but I don't see the tag ....
[00:10] <NCommander> TheMuso, oh, it seems tags aren't automatically pushed
[00:12] <TheMuso> NCommander: aaaaahhhhh!
[00:13] <NCommander> TheMuso, lets try that again
[00:13] <TheMuso> This is a nice learning experience.
[00:13] <NCommander> I dunno fi I call the lack of automatic pushing of tags a feature or a bug
[00:13] <NCommander> Its uploading now
[00:13] <TheMuso> Ok.
[00:14] <TheMuso> I call it a bug personally, but thats just me.
[00:14] <NCommander> SOmeone should note that you need to git push --tags :-)
[00:14] <TheMuso> Yeah.
[00:14] <NCommander> Its designed so if you pull someone elses branch, you don't get private tags from during release
[00:14] <NCommander> wow, 10MB worth of tags
[00:14] <NCommander> Linus has been busy ;-)
[00:15] <TheMuso> Ouch.
[00:15] <NCommander> (ubuntu-ports tags are obviously enough Ubuntu-ports vs Ubuntu so we can't accidently get the same tag)
[00:15] <TheMuso> NCommander: Well you probably need to change the debian/rules files to look for those tags then.
[00:15] <TheMuso> Otherwise the insertchanges et al commands will fail.
[00:15] <NCommander> Probably
[00:17] <NCommander> TheMuso, that change is in my branch, once 1.1 is released, it will be available for 1.2 (or 2.1)
[00:17] <TheMuso> NCommander: ok.
[00:24] <NCommander> TheMuso, TADA http://kernel.ubuntu.com/git?p=mcasadevall/ubuntu-jaunty-ports.git;a=summary
[00:25] <NCommander> The changelog is amusingly long
[00:25] <NCommander> and
[00:25] <NCommander> I think incorrect
[00:25] <NCommander> Damn it
[00:25] <NCommander> Freaking insert changes pulled in stuff it shouldn't
[00:26] <NCommander> actually, wait, it only grabbed 2.6.27-><IP_ADDRESS>
[00:26] <NCommander> Which is correct
[00:27] <TheMuso> NCommander: ok.
[00:27] <NCommander> Ok, so just grab my branch, build a source package (with a orig.tar.gz), sign and upload
[00:28] <TheMuso> Will do.
[00:53] <TheMuso> NCommander: Do you want me to give it a test build on PowerPC hardware?
[01:42] <NCommander> TheMuso, sure
[01:42] <NCommander> (I tested it on my box, but I haven't tested it since fixing the other archs, but there were no code changes)
[01:53] <TheMuso> Right.
[01:53] <NCommander> TheMuso, if you do, save the abi folder
[01:53] <NCommander> We'll need to generate those on all architectures from this release forward, since we'll have lbm and lrm soon
[01:53] <TheMuso> NCommander: I'm building in an LVM snapshot with sbuild.
[01:54] <NCommander> oh
[01:54] <NCommander> Ok
[01:54] <TheMuso> I can grab it during the build however if you like.
[01:54] <NCommander> Its not a priority until we start getting lrm and module packages
[01:54] <TheMuso> Is it created early on?
[01:54] <NCommander> No
[01:54] <NCommander> Towards the very end of the build
[01:55] <TheMuso> Right.
[02:00] <TheMuso> NCommander: actually I will build it manually, so I can get the ABI folder.
[02:00]  * NCommander nods
[02:01] <TheMuso> NCommander: I thought there was a bug opened for ports kernel in intrepid to not use gcc 4.1 for powerpc, yet I see it in the build-deps.
[02:01] <NCommander> I haven't cleared it yet
[02:01] <NCommander> 1.2 build task
[02:02] <TheMuso> ok
[02:02] <NCommander> (doko wants to zap 4.1, once 1.1 is uploaded, that will be the first thing I do, since I need to make sure we don't have any nasty ices on any platform and still have working kernels)
[02:02] <NCommander> i.e., I want a baseline to work against
[02:03] <TheMuso> Right.
[02:34] <TheMuso> NCommander: Kernels are cooking.
[02:34] <NCommander> I thought I smelled something burning ;-)
[02:34]  * NCommander runs from the bad pun
[02:34] <TheMuso> It still made me laugh however.
[02:35] <NCommander> Yay, 7 packages pending uploading (with an eight pending successful pbuildering)
[02:35]  * TheMuso slaps his head. I should have told it to use both CPUs to build faster...
[02:35] <NCommander> -j2 is broken
[02:36] <TheMuso> Oh ok.
[02:36] <TheMuso> That solves that then.
[02:36] <NCommander> It kinda works
[02:36] <NCommander> But you get a weird race condition which causes dpkg to explode
[02:36] <TheMuso> Right.
[02:36] <NCommander> I need to sit down and debug it at some point
[02:36] <TheMuso> I wonder if that can be sorted out.
[02:36] <NCommander> Enviornmental variable which just passed -j to the kernel build
[02:36] <NCommander> WHich is what is already implemented
[02:36] <TheMuso> Yeah I saw that.
[02:36] <NCommander> (KERNEL_CONCURENCY_LEVEL or something)
[02:37] <TheMuso> Yeah.
[03:19] <TheMuso> NCommander: powerpc kernel cooked, powerpc-smp kernel now cooking.
[03:21]  * NCommander holds the extinisher ready
[03:22] <TheMuso> lol
[03:37] <TheMuso> NCommander: powerpc64-smp now cooking.
[03:38] <NCommander> TheMuso, can you test run them?
[03:38] <TheMuso> NCommander: As in try to boot from them? Sure.
[03:50] <NCommander> TheMuso, since we're on the topic of things to be done
[03:50] <NCommander> TheMuso, can I get a few sponsoring on other packages?
[03:56] <TheMuso> NCommander: Sure. Shall we take it to a more appropriate channel?
[03:56] <NCommander> motu or devel, your pick
[03:57] <TheMuso> NCommander: doesn't bother me, whatever suits you.
[03:57] <TheMuso> :p
[03:57] <TheMuso> \/c
[04:47] <TheMuso> Wow documentation takes a while.
[04:50] <NCommander> TheMuso, yup
[04:50]  * NCommander should have told you to debuild -B
[04:51] <TheMuso> Oh well.
[04:51] <NCommander> TheMuso, did you get your zinc acocunt fixed?
[04:53] <TheMuso> NCommander: Its in progress I believe.
[05:05] <TheMuso> NCommander: kernels done.
[05:05] <TheMuso> I can smoke test powerpc, and powerpc64-smp. I don't have a generic powerpc-smp box though.
[05:05] <NCommander> now do they boot?
[05:05] <TheMuso> Bout to try powerpc64-smp.
[05:06] <NCommander> powerpc-smp will work fine on powerpc, or on a powerpc64-smp box
[05:06] <TheMuso> Ok.
[05:08] <TheMuso> NCommander: booting into powerpc64-smp.
[05:08]  * NCommander crosses fingers
[05:09] <TheMuso> It boots.
[05:11] <TheMuso> Ok sound works, all disks present and correct, hrm not sure what else to check.
[05:16] <NCommander> Good enough for me
[05:16] <NCommander> The powerpc kernel been tested
[05:16] <TheMuso> testing powerpc-smp now.
[05:16] <NCommander> TheMuso, just as a reminder, remember to leave my name on the changelog (on the bottom) so I get the build failure notices if any occur :-)
[05:17] <TheMuso> NCommander: since you fixed the changelog, that is not a problem.
[05:20] <TheMuso> hrm powerpc-smp doesn't want to boot.
[05:20] <TheMuso> on my G5./
[05:20] <NCommander> coooooool
[05:20] <TheMuso> yeah
[05:20] <TheMuso> it brings up a screen with a lot of OpenFirmware stuff, or thats what it looks like.
[05:22] <TheMuso> ok will try the powerpc and powerpc-smp kernels on my mini.
[05:23] <NCommander> Hrm
[05:23] <NCommander> the smp kernel might be hosed
[05:23] <TheMuso> haha and the old boot option is broken. Time to dig out a desktop CD from hardy...
[05:23] <NCommander> I'll have to smash it with a stick but unless I can find someone with a 32 bit SMP box
[05:26] <NCommander> TheMuso, maybe the -smp kernel for some ungodly reason tries to put the G5 into little endian mode which would crash and burn
[05:28] <TheMuso> possibly.
[05:29] <TheMuso> NCommander: what makes you think that?
[05:29] <NCommander> Its the only thing that could possibly cause the kernel to fault all the way back into open firmware
[05:29] <TheMuso> NCommander: right
[05:29] <NCommander> At least thats what I'm thinking
[05:29] <NCommander> If it works on your mini, yay, if not
[05:29] <NCommander> 1.2 :-)
[05:30]  * NCommander hears a gunshot
[05:30]  * TheMuso slaps his head.
[05:30] <TheMuso> I was trying to boot old on my mini, not the G5.
[05:31] <NCommander> oh
[05:31] <NCommander> Your mini crashed and burned
[05:31] <NCommander> Nice :-/
[05:31] <TheMuso> no
[05:31] <NCommander> Wait
[05:31] <NCommander> huh?
[05:31] <NCommander> What machine failed to boot the smp kernel?
[05:32] <TheMuso> When I tried to boot into another kernel on what I thought was my G5, it didn't work, but it was on my mini.
[05:32] <NCommander> Oh I see
[05:32] <TheMuso> the G5 failed to boot the powerpc-smp kernel.
[05:32]  * NCommander is resmoketesting the -smp kernel
[05:32] <NCommander> I dunno why we have an non-smp/smp varient
[05:32] <NCommander> Every other architecture is compiled to smp
[05:33] <TheMuso> Yeah I know what you mean.
[05:34] <NCommander> THere may be issues with the smp kernel on non-smp PPC hardware
[05:34] <NCommander> THats the only reason I can think of
[05:34] <NCommander> The G4 made it through a full startup with the SMP kernel
[05:34] <NCommander> (its a single chip box)
[05:34] <TheMuso> Right.
[05:34] <NCommander> I think there must be hardware the SMP kernel crashes and burns with
[05:35] <NCommander> TheMuso, I think we can write the issue as "Needs Investigation" and upload it
[05:35] <TheMuso> Ok.
[05:40] <NCommander> TheMuso, I just had a brainwave
[05:40] <NCommander> TheMuso, your mini might have faulted because the kernel uses OpenFirmware to determine the presence of a second processor
[05:40] <NCommander> Want to be on your mini crashed and burned due bad OF information?
[05:40] <NCommander> *bet
[05:41] <TheMuso> NCommander: it was the G5.
[05:41] <TheMuso> NCommander: not the mini.
[05:42] <NCommander> Oh!
[05:42] <NCommander> same point applies ;-)
[05:42] <TheMuso> Right.
[05:42] <TheMuso> But powerpc64-smp worked.
[05:42] <NCommander> and powerpc-smp worked on non-smp hardware
[05:43] <NCommander> We need someone with an SMP G4
[05:43] <TheMuso> Yep.
[05:47] <TheMuso> ok powerpc works on the mini
[05:49] <NCommander> so either smp is broken on smp hardware :-/, or smp is broken on smp64
[05:52] <TheMuso> NCommander: NCommander Well 64-smp is fine, as I am now back on that with my G5, and both CPUs are showing.
[05:52] <NCommander> I think infinity or lamont have to have a multicore non-SMP G5
[05:53] <NCommander> can you boot a powerpc kernel on your G5?
[05:53] <NCommander> (maybe its a general 64-bit issue vs. smp)
[05:53] <TheMuso> NCommander: the powerpc kernel non-smp boots fine.
[05:53] <NCommander> ok
[05:53] <NCommander> We'll have to mark that on the Needs Debugging list
[05:59] <TheMuso> NCommander: powerpc-smp boots on mini.
[06:00] <NCommander> woooo
[06:00] <NCommander> so its just a 64-bit issue
[06:01] <TheMuso> sounds like it.
[06:02] <NCommander> do we care enough to fix it at this very moment?
[06:03] <TheMuso> I don't.
[06:06]  * NCommander doesn't
[06:13] <TheMuso> NCommander: i have some things to do so I'll look further into this later.
[06:13] <NCommander> TheMuso, the smp crash, or uploading ;-)?
[06:13] <TheMuso> NCommander: uploading.
[06:13] <NCommander> ok, no
[06:13] <NCommander> *np
[07:32] <NCommander> ah, abogani
[07:32] <abogani> NCommander: Hi
[07:33] <NCommander> abogani, I've been working on linux-rt-powerpc, and I found a rather disturbing problem
[07:33] <NCommander> The current rt kernel in Intrepid isn't actually RT :-/
[07:33] <abogani> :-?
[07:33] <NCommander> (CONFIG_PREEMPT_RT is not defined)
[07:34] <NCommander> and I can be blamed for it
[07:34]  * NCommander whacks head on the desk
[07:34] <abogani> No way: it is defined.
[07:35] <NCommander> Nope
[07:35] <NCommander> abogani, here's the debdiff
[07:36] <NCommander> oh wait
[07:37] <NCommander> bah
[07:37] <NCommander> Screw me, I can't spell "PREEMPT"
[08:05] <NCommander> morning smb_tp
[08:06] <smb_tp> Good morning NCommander
[08:06] <NCommander> smb_tp, how goes your morning
[08:07] <smb_tp> NCommander, Good so far. :) Just got the first coffee. Saw your mail
[08:08] <NCommander> smb_tp, TheMuso will be uploading the first ports kernel soon, and I'm bending linux-ports-lrm into shape :-)
[08:10] <smb_tp> NCommander, Sounds great. :) I guess I will give the mail some time today to be seen by others and then pull it to the repo.
[08:11] <NCommander> \o/
[08:11] <NCommander> smb_tp, if you have sometime at some point to sit down with the ia64 config files, and figure out what things should be built as modules, it would be apperiated because then I can fix d-i for ia64
[08:16] <smb_tp> NCommander, I only had a config that compiled (but had to discard serial-modules) and produced some udebs but whether this really is useful for the installer, I don't know.
[08:16] <NCommander> smb_tp, someone who knows the hardware needs to sitdown and smash the kernel into shape :-/. Even HPPA has working d-i/udeb support and thats the architecture thats usually broken
[08:18] <smb_tp> NCommander, True. I will try to ask BenC whether he got a little time to help. At least he has the HW
[08:18] <NCommander> Oh, I thought you had ia64
[08:18] <NCommander> d'oh
[08:20] <smb_tp> NCommander, No, I only have access to one (but only as user, so I can't install new kernels)
[08:20] <NCommander> oh right
[14:12] <nodeboy_999> hello
[14:12] <nodeboy_999> does apt-get <linux-kernel> provide a static or dynamic kernel image for any given kernel?
[15:04] <drunkenkilla> hello
[15:04] <drunkenkilla> i got a problem
[15:05] <drunkenkilla> i can't change the brightness...the fn-keys and the applet in the panel doesn't work
[15:05] <drunkenkilla> i tested even now pre-release of fedora 10 and i could change the brigthness with the applet in the panel
[15:15] <mjg59> F10 implements opregion support which is required for backlight control on a bunch of Intel graphics laptops
[15:15] <mjg59> It'll be in 2.6.28 of the upstream kernel, but it's not in Intrepid
[17:07] <psusi> isn't there a libata option somewhere for verbose debugging output?
[17:11] <rtg> lamont: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 has finished building. this time it should _really_ fix your b44 issue.
[17:12] <lamont> rtg: and which suite does it show up in, I wonder?
[17:12] <lamont> intrepid-proposed?
[17:13] <rtg> lamont: yes.
[17:13] <lamont> kewl
[17:14] <rtg> lamont: adventurous souls such as yourself should always have -proposed enabled :)
[17:14] <lamont> heh.  not.
[17:14] <lamont> well. maybe pinned at 25 :-)
[18:05] <BenC1> rtg: I'm worried about the patch that fixes backlight key...it's not in upstream yet
[18:06] <drunkenkilla> BenC1: which patch? i have problems too witch backlight
[18:07] <BenC1> drunkenkilla: what's the problem you are having?
[18:07] <drunkenkilla> i can't change the brightness
[18:08] <drunkenkilla> i'm using ubuntu 8.10 and i can't change the brightness with the fn-keys and the applet in the panel
[18:08] <BenC> Could be fixed by this patch
[18:08] <drunkenkilla> but today i tested pre-release of fedora 10 and i could change the brightness with the applet, but not with the fn-keys
[18:09] <BenC> The case I'm fixing is where the brightness key causes two key press events
[18:09] <drunkenkilla> i will show you dmesg...
[18:10] <drunkenkilla> BenC: http://paste.ubuntu.com/67995/
[18:13] <BenC> drunkenkilla: full dmesg would be better
[18:15] <drunkenkilla> BenC: http://paste.ubuntu.com/67998/
[18:29] <drunkenkilla> re
[18:50] <drunkenkilla> BenC: when will come this patch?
[18:51] <BenC> drunkenkilla: not sure
[18:52] <mjg59> BenC: You get an ACPI key event and an event from the keyboard?
[19:46] <psusi> what did you have to do to see KERN_DEBUG printks again?
[20:05] <Pici> Howdy kernel people.  It looks like the current kernel compiling help on help.u.com assumes that the user is running Intrepid. I don't really know enough about kernel compiling to split out the directions, but this is the wiki diff that appears to be the culprit: https://help.ubuntu.com/community/Kernel/Compile?action=diff&rev1=69&rev2=61
[20:06] <Pici> linux-kernel-devel is not on Intrepid and makedumpfile isnt on anything pre intrepid
[21:02] <BenC> mjg59: yeah
[21:11] <NCommander> hey BenC
[21:45] <BenC> NCommander: hey
[21:46] <NCommander> BenC, did you see my email to the list?
[22:00] <mjg59> BenC: I suspect gnome-power-manager is the right place to handle that


[06:54] <oSoMoN> good morning desktoppers
[07:03] <didrocks> good morning
[07:04] <oSoMoN> salut didrocks
[07:06] <duflu> Hi oSoMoN and didrocks
[07:08] <ricotz> good morning!
[07:09] <ricotz> hey didrocks oSoMoN duflu
[07:10] <duflu> Morning ricotz
[07:10] <didrocks> salut oSoMoN, hey duflu, ricotz
[07:11] <oSoMoN> hey duflu, ricotz
[07:11] <ricotz> could someone please take a look at the leftover binaries of llvm-toolchain-snapshot in impish-proposed/universe - https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/1:14~++20210924122635+4a57f5d1e1c5-1~exp1
[07:12] <ricotz> those NBS packages should be removed
[07:19] <didrocks> ricotz: any news on libreoffice -> epiphany-browser? We have our MIR team meeting later today
[07:40] <ricotz> didrocks, the libreoffice-help-* packages depend on firefox and as alternative on other browsers, using e.g. "apt --install-recommends install ..." is doing the right thing
[07:41] <ricotz> so component-mismatch script enforces some additional requirements on purpose or on error?
[07:42] <didrocks> ricotz: it could be a false positive, but someone has to ensure this first
[07:42] <didrocks> however, libreoffice is still blocked on proposed:
[07:42] <xypron> The thunderbird snap fails to save under /tmp (which may be correct for given authorization) but gives no feedback. For packages it is clear how to report a bug. But where are bugs collected per snap?
[07:42] <jpnurmi> good morning
[07:42] <didrocks> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html -> libreoffice (1:7.2.5~rc2-0ubuntu1 to 1:7.3.1~rc1-0ubuntu3)
[07:42] <didrocks> Depends: libreoffice python3-defaults (not considered)
[07:43] <jibel> good morning all
[07:43] <didrocks> I don’t think this is the issue for c-m output, but the archive won’t make it migrating
[07:43] <ricotz> didrocks, afaik the component mismatch isn't/won't blocking it, correct?
[07:43] <didrocks> ricotz: it seems that this one is not listed, but there is still a blocking one
[07:43] <didrocks> still wondering about all those false positives… It all started when we allowed build-deps to be in universe… :/
[07:43] <didrocks> hey jibel
[07:45] <ricotz> didrocks, yeah, python3.10 is holding back things currently
[07:45] <didrocks> ack, python transition thus
[07:46] <jibel> Salut didrocks
[07:46] <ricotz> didrocks, cjwatson had a short look at it and the libreoffice mismatch seemed not logical to him as well
[07:47] <didrocks> ricotz: ack, so it’s a false positive, I’ll report this. We really need someone to have a look at what/when things broke in this scripts, but I think this is really related to build-deps in universe…
[07:47] <didrocks> we can’t maintain a whitelist by hand
[07:47] <ricotz> didrocks, fyi https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?id=71f9642851d16e75deba9b8a47b08455d4c5bd8a
[07:47] <didrocks> ricotz: thanks for investigating it!
[07:47] <didrocks> yeah, sounds about right
[07:48] <ricotz> the original problem without firefox being first in the list made kind of sense though
[07:49] <didrocks> indeed, I think the root cause was correct
[07:49] <didrocks> then, why the fix then hasn’t worked from a c-m perspective… This is puzzling
[07:50] <ricotz> maybe it checks all alternatives
[07:50] <didrocks> no, the list will be way longer if that was the case
[07:51] <didrocks> we have a lot of alternatives from packages in universe if you take all main into consideration…
[07:51] <ricotz> alright
[07:51] <didrocks> same with virtual packages :/
[07:56] <seb128> goood morning desktopers
[07:57] <seb128> didrocks, I saw your emails and I already poked at it yesterday but I don't understand how component mismatch works and why it insists in listing rdepends of dev binaries that have been demoted :-(
[07:57] <seb128> it feels like a bug in the report to me
[07:58] <seb128> I can try debugging the report script but that's not going to be be this week with feature freeze
[07:58] <seb128> oh and hey didrocks, ricotz, how are you today? ;-)
[08:01] <didrocks> seb128: hey! Yeah, it’s more to track that those are really false positives and assert it. If those are real non issues, that would be an argument for next week IRL MIR meeting that we need someone to have a look at this script and why it reports all those. We can’t have an ever growing list of false positives… But we need someone to do it.  How are you?
[09:11] <oSoMoN> good morning seb128, jpnurmi
[09:11] <jpnurmi> hey duflu seb128 oSoMoN
[09:11] <oSoMoN> xypron, feel free to file a bug at https://bugs.launchpad.net/ubuntu/+source/thunderbird/+filebug (make sure to specify that this is the snap)
[09:12] <seb128> lut oSoMoN
[09:12] <seb128> duflu, I'm alright thanks, slept better this night as the storm was over
[09:12] <xypron> Thanks oSoMoN
[09:12] <seb128> xypron, oSoMoN what's the issue?
[09:12] <seb128> ah, I saw the log now
[09:13] <seb128> xypron, define 'fail to save'? it's saving fine to /tmp afaik, it's just that snap have a private /tmp so that's not the /tmp from your system
[09:13] <ricotz> seb128, hey, I am alright :)
[09:14] <xypron> seb128: in the save dialogue I specifically chose /tmp
[09:15] <xypron> seb128: a few days before this was enough to save to the real /tmp
[09:16] <seb128> xypron, depends if you are using portals I guess
[09:17] <xypron> seb128: sorry I am not aware of what portals are.
[09:17] <seb128> xypron, a way to access the real filesystem from the snap
[09:18] <seb128> xypron, best that you open a bug as suggested by o_SoMoN , please provide the details on the system, distro version, desktop environment used, snap channel, etc
[09:18] <xypron> ok
[09:18] <seb128> for what it is worth 91.6.1 still use the portals and save to the system /tmp for me
[11:47] <xypron> seb128: after rebooting the problem was gone. Maybe some interference with updates.
[12:20] <seb128> xypron, maybe...
[13:01] <jbicha> good morning
[13:02] <KGB-2> gnome-pkg-tools signed tags 84b9437 Marco Trevisan ubuntu/0.22.4ubuntu2 * gnome-pkg-tools Debian release 0.22.4ubuntu2 * https://deb.li/3eCj
[13:02] <KGB-2> gnome-pkg-tools ubuntu/master e53a19b Marco Trevisan * pushed 12 commits (first 5 follow) * https://deb.li/32iMR
[13:02] <KGB-2> gnome-pkg-tools ubuntu/master 6cdf5e4 Gunnar Hjalmarsson debian/changelog pkg-gnome.team * Add myself to pkg-gnome.team * https://deb.li/nFv
[13:02] <KGB-2> gnome-pkg-tools ubuntu/master 506afe4 Gunnar Hjalmarsson debian/changelog * Upload to unstable * https://deb.li/NoXi
[13:03] <KGB-2> gnome-pkg-tools ubuntu/master 765f99d Marco Trevisan (Treviño) pkg-gnome.team * pkg-gnome.team: Update me to match my $DEBFULLNAME and $DEBEMAIL * https://deb.li/UELM
[13:03] <KGB-2> gnome-pkg-tools ubuntu/master 2fb56a3 Marco Trevisan (Treviño) debian/changelog * Update changelog * https://deb.li/37agj
[13:03] <KGB-2> gnome-pkg-tools ubuntu/master 3b5d218 Marco Trevisan (Treviño) debian/changelog * Upload to unstable * https://deb.li/mzV4
[13:42] <seb128> jbicha, hey, how are you?
[13:44] <jbicha> good, how are things?
[13:50] <seb128> doing alright, busy as expected on a feature freeze week, right? ;)
[14:05] <jbicha> yes!
[14:11] <jbicha> seb128: it looks like gjs is built on i386. Can you enable mozjs91 to build on i386 too?
[14:13] <seb128> jbicha, I hate the i386 whitelisting business :/ let me check
[14:59] <seb128> jbicha, checking your versions changes and the description, the issue with tracker is that the GNOME_NEW_VERSION regexp expect a SERIE.REV(.alpha|beta...)
[14:59] <seb128> and they use a third number
[15:00] <jbicha> oh cool
[15:00] <seb128> jbicha, so you either need to come with a tweak to that regexp or just don't use GNOME_FTP_URL and write manually the regexp
[15:00] <jbicha> ok
[15:01] <seb128> k, let's do incoming rls bugs review for those interested
[15:02] <seb128> I think Ken is busy with other things but let's do it anyway
[15:02] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html
[15:02] <seb128> bug #1960387 is being discussed upstream, we should target it
[15:03] <kenvandine> i'm here
[15:03] <seb128> the at-spi one I'm going to handle
[15:03] <seb128> kenvandine, hey :)
[15:03] <seb128> bug #1961197
[15:04] <seb128> the current comment suggest it's probably not a rls target to me
[15:06] <kenvandine> agreed
[15:07] <seb128> k, let's wontfix
[15:07] <seb128> I'm reading the activity on bug #1953052
[15:07] <seb128> turns out that it is due to pipewire
[15:08] <seb128> in any case sounds like something to fix, +1 for targetting I would say
[15:09] <kenvandine> +1
[15:10] <seb128> that's if for j incoming
[15:10] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html
[15:10] <seb128> those are assigned
[15:11] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html
[15:11] <seb128> no desktop bugs
[15:11] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-tracking-bug-tasks.html
[15:12] <seb128> bug #1955044 is new and up for sponsoring
[15:12] <seb128> I will review it
[15:13] <seb128> the other ones we already discussed and are being worked or incomplete
[15:13] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[15:13] <seb128> no desktop there
[15:14] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[15:14] <seb128> nothing new to review on that one
[15:15] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[15:15] <seb128> no desktop section
[15:15] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[15:15] <seb128> bug 1961565 to be assigned to Olivier also for bionic
[15:16] <seb128> and I think that's it for this round
[15:16] <seb128> kenvandine, thanks!
[15:17] <kenvandine> easy day :)
[15:17] <kenvandine> seb128: thank you!
[15:19] <kenvandine> seb128: snap-store in the jammy daily images hangs on first run, I'm resetting my VM and going to collect verbose logs
[15:19] <seb128> kenvandine, live session or installed system?
[15:20] <seb128> kenvandine, but it's not a new issue, I had been hitting that problem often when trying edge builds
[15:20] <kenvandine> installed
[15:20] <kenvandine> i couldn't repro it on an existing install, only on first run
[15:21] <kenvandine> edge == stable/ubuntu-22.04 now
[15:21] <seb128> well I'm often doing 'first run' when testing edge
[15:21] <seb128> like I wipe ~/snap/snap-store
[15:22] <seb128> it doesn't need to be a fresh install, might make easier to test or debug
[15:22] <seb128> it's stucked on the loading bar right?
[15:22] <seb128> I usually blame packagekit but maybe wrongly...
[15:23] <kenvandine> perhaps
[15:23] <kenvandine>  --verbose should help here
[15:23] <kenvandine> a killall and run again works
[15:31] <seb128> right, that's what I also noticed
[15:51] <Trevinho> jbicha: do we care having gjs for i386 in ubuntu?
[16:00] <jbicha> I don't need gjs on i386
[18:39] <KGB-0> gnome-bluetooth3 pristine-tar 4a0dbed Jeremy Bicha gnome-bluetooth3_42~beta.orig.tar.xz.delta gnome-bluetooth3_42~beta.orig.tar.xz.id * pristine-tar data for gnome-bluetooth3_42~beta.orig.tar.xz * https://deb.li/5nrU
[18:39] <KGB-0> gnome-bluetooth3 signed tags 7c6e145 Jeremy Bicha upstream/42_beta * Upstream version 42~beta * https://deb.li/3P2Y7
[18:39] <KGB-0> gnome-bluetooth3 upstream/latest a4dedf0 Jeremy Bicha * pushed 343 commits (first 5 follow) * https://deb.li/3nFTF
[18:40] <KGB-0> gnome-bluetooth3 upstream/latest 2a1f37c Fran Dieguez po/gl.po * Update Galician translation * https://deb.li/crti
[18:40] <KGB-0> gnome-bluetooth3 upstream/latest e01173e Matej Urbančič po/sl.po * Update Slovenian translation * https://deb.li/3GBBh
[18:40] <KGB-0> gnome-bluetooth3 upstream/latest 8268877 Leônidas Araújo po/pt_BR.po * Update Brazilian Portuguese translation * https://deb.li/3wbf2
[18:40] <KGB-0> gnome-bluetooth3 upstream/latest 09bc7ea Rafael Fontenelle po/pt_BR.po * Update Brazilian Portuguese translation * https://deb.li/itn3C
[18:40] <KGB-0> gnome-bluetooth3 upstream/latest 5ef0932 Jonas Dreßler lib/bluetooth-device.c * lib: Add getter for connectable property * https://deb.li/5KU
[18:48] <KGB-0> tilix pristine-tar b056bd4 Matthias Klumpp tilix_1.9.5.orig.tar.gz.delta tilix_1.9.5.orig.tar.gz.id * pristine-tar data for tilix_1.9.5.orig.tar.gz * https://deb.li/ixyVz
[18:49] <KGB-0> tilix upstream/latest 8094278 Matthias Klumpp * pushed 65 commits (first 5 follow) * https://deb.li/k7p1
[18:49] <KGB-0> tilix upstream/latest e064f4d George Bogdanoff po/ru.po * l10n: Update Russian * https://deb.li/3W1bN
[18:49] <KGB-0> tilix upstream/latest 7cb2c59 Jan Beich data/meson.build * meson: drop unused argument for i18n.merge_file() (#2081) * https://deb.li/eCHV
[18:49] <KGB-0> tilix upstream/latest e057739 David King experimental/flatpak/ com.gexperts.Tilix.yaml gtkd3-pkgconfig.patch stemmer-dynlib.patch vte291-exceptions-gcc811.patch * Update flatpak manifest (#2058) * https://deb.li/v5Ul
[18:49] <KGB-0> tilix upstream/latest 87ac57f luk1337 source/gx/tilix/ sidebar.d terminal/terminal.d * Don't check GtkDragResult (#2062) * https://deb.li/3oW1I
[18:49] <KGB-0> tilix upstream/latest a4eadbb luk1337 source/gx/tilix/terminal/terminal.d * Don't add application/x-rootwindow-drop to dragSourceSet targets (#2063) * https://deb.li/SWnj
[18:49] <KGB-0> tilix tags 385238d Matthias Klumpp upstream/1.9.5 * Upstream version 1.9.5 * https://deb.li/3Aysg
[21:06] <KGB-2> eog-plugins signed tags 6a654bc Jeremy Bicha upstream/42_alpha * Upstream version 42~alpha * https://deb.li/30Ij0
[21:06] <KGB-2> eog-plugins upstream/latest 43df869 Jeremy Bicha * pushed 21 commits (first 5 follow) * https://deb.li/9v0x
[21:07] <KGB-2> eog-plugins upstream/latest 45931c4 Krifa75 (6 files in 2 dirs) * drop hide-titlebar * https://deb.li/3swCE
[21:07] <KGB-2> eog-plugins upstream/latest 1e4dc59 Felix Riemann configure.ac * Post-release version bump * https://deb.li/CwA4
[21:07] <KGB-2> eog-plugins upstream/latest 5410ae1 Felix Riemann configure.ac * Post-branch version bump * https://deb.li/3cIhD
[21:07] <KGB-2> eog-plugins upstream/latest 4490ba7 Felix Riemann (6 files in 2 dirs) * Merge branch 'drop-hide-titlebar' into 'master' * https://deb.li/6Dij
[21:07] <KGB-2> eog-plugins upstream/latest 5a6a071 Felix Riemann po/POTFILES.in * po: Remove dropped hide-titlebar plugin from translation * https://deb.li/iwvcR
[21:07] <KGB-2> eog-plugins pristine-tar 856e532 Jeremy Bicha eog-plugins_42~alpha.orig.tar.xz.delta eog-plugins_42~alpha.orig.tar.xz.id * pristine-tar data for eog-plugins_42~alpha.orig.tar.xz * https://deb.li/KDWi
[21:35] <KGB-2> babl signed tags 9474a50 Jeremy Bicha upstream/0.1.90 * Upstream version 0.1.90 * https://deb.li/3cuoN
[21:36] <KGB-2> babl upstream/latest f2402d2 Jeremy Bicha * pushed 81 commits (first 5 follow) * https://deb.li/FxbU
[21:36] <KGB-2> babl upstream/latest 2f40f47 Øyvind Kolås babl/babl-fish-path.c * babl: do luts for 2->16 byte fishes * https://deb.li/3dJkF
[21:36] <KGB-2> babl upstream/latest f2c4b35 Øyvind Kolås babl/babl-fish-path.c babl/babl.h tools/babl-benchmark.c * babl: clean up compiler warnings * https://deb.li/uD57
[21:36] <KGB-2> babl upstream/latest 76eb8ae Øyvind Kolås babl/babl-cache.c * babl: fix fix bpp initialization when loaded from cache * https://deb.li/ip8Zd
[21:36] <KGB-2> babl upstream/latest debe249 Øyvind Kolås extensions/sse2-float.c * sse2-float: correctly handle associted alpha in remainder * https://deb.li/WZg4
[21:36] <KGB-2> babl upstream/latest 21d6df0 Øyvind Kolås tools/ babl-benchmark.c babl-verify.c * tools: inhibit cache use in lut-verify and babl-benchmark * https://deb.li/3Z8ID
[21:37] <KGB-2> babl pristine-tar dbc7bb8 Jeremy Bicha babl_0.1.90.orig.tar.xz.delta babl_0.1.90.orig.tar.xz.id * pristine-tar data for babl_0.1.90.orig.tar.xz * https://deb.li/AJlj
[23:54] <KGB-0> gnome-text-editor signed tags 9d09da1 Jeremy Bicha upstream/42_beta1 * Upstream version 42~beta1 * https://deb.li/3fYKd
[23:55] <KGB-0> gnome-text-editor upstream/latest 7a7afb6 Jeremy Bicha * pushed 191 commits (first 5 follow) * https://deb.li/IiDl
[23:55] <KGB-0> gnome-text-editor upstream/latest 2aee247 Marek Černocký po/cs.po * Updated Czech translation * https://deb.li/3eCsI
[23:55] <KGB-0> gnome-text-editor upstream/latest 6d61a31 Danial Behzadi po/ LINGUAS fa.po * Add Persian translation * https://deb.li/3k7zE
[23:55] <KGB-0> gnome-text-editor upstream/latest c12d4eb Daniel Mustieles help/ LINGUAS es/es.po * Add Spanish translation * https://deb.li/iWYUe
[23:55] <KGB-0> gnome-text-editor upstream/latest 868c6d5 Matej Urbančič po/sl.po * Update Slovenian translation * https://deb.li/pS70
[23:55] <KGB-0> gnome-text-editor upstream/latest 980bd3c Christian Hergert src/editor-page.ui * page: enable smart-home-end before behavior * https://deb.li/3Q5B2
[23:55] <KGB-0> gnome-text-editor pristine-tar 15c6c66 Jeremy Bicha gnome-text-editor_42~beta1.orig.tar.xz.delta gnome-text-editor_42~beta1.orig.tar.xz.id * pristine-tar data for gnome-text-editor_42~beta1.orig.tar.xz * https://deb.li/1Yfi


[04:46] <eMinja> Anyone on here able to help at the moment?
[12:13] <ogra_> srwarren, sorry, i still owe you an answer, https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html should help to get rootfs builds