=== liushuyu1 is now known as liushuyu === liushuyu1 is now known as liushuyu [08:09] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Noble | Patch Pilots: juliank [10:04] LocutusOfBorg: Hi! I noticed you uploaded virtualbox several times on Jamy [10:04] LocutusOfBorg: did you notice there's a new hwe-6.8 kernel, and virtualbox FTBFS against it? [10:05] https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/v/virtualbox/20240620_090313_c0a8a@/log.gz [10:06] flag, why nobody asked me to fix? [10:06] I mean, how can a kernel be released with regressions [10:06] LocutusOfBorg: it's in proposed ATM [10:08] ok so the process works thanks [10:08] I'll have a look! [10:08] sadly for 6.1.50 there are no new releases, I'll need to cherry-pick from 7.x [10:08] LocutusOfBorg: sounds good to me! :) [10:09] FWIW, I think there was a problem with the process last time that allowed the kernel to be released with an outstanding issue but I think that was investigated and fixed. [10:10] We do care :) [11:49] rbasak, I know this is why I asked :) [11:49] better make sure we don't regress [14:57] dwarves was updated to new upstream release during Noble, Debian was still at an old release. But now Debian has a newer release, is there any reason that dwarves should stay at 1.25.0 in Ubuntu ? === rkratky__ is now known as rkratky [15:10] rbasak, hey. Could you check if https://code.launchpad.net/~nteodosio/update-manager/+git/update-manager/+merge/469201 is good enough for you from a SRU reviewer perspective? I'm unsure how specific you want the exception handler to be and want to avoid upload to all the series to have to be told that we need to redo it again [15:24] sudip: someone just needs to manually merge it [15:27] ack, thanks jbicha, will do that.. [15:52] seb128: I'm open to discussion on this, but I'm not clear why we're catching this at all. If there's a pro client library issue, do we not want the application to crash and for us to be told about it via apport/whoopsie? [15:56] seb128: perhaps there's a case though that we don't want users to be complaining that "Pro" made their non-Pro-enabled systems crashed, but if we want that then I think we need to think very carefully about it. Maybe try to trigger a crash report regardless, just not crashing update manager in the process? [17:00] rbasak, afaik the issue is that we are unclear why the pro client errors out for those users, but the consequence is that update-manager is not functional due to the pro integration. Which as a side effect halted the SRU since the pro integration was added in a SRU and such it's a regression compared to the existing codebase. Ideally we would know what the pro client issue is and fix it, but since we don't the alternative is [17:00] to make update-manager at least not error out... [17:01] I saw your comment on the MP now, thanks [18:55] ahem, why am I receiving build failure notifications for a reprepro build for Bionic in a random PPA? [18:56] somehow I indirectly own the team "Tritemio Maintainers"? [18:56] ah, I get it, nvm [20:24] I have a confusion. I am looking at a package which should be sync as the delta is now added to Debian. But needs another change, will that be a merge with no remaining change, drop changes and new changes or should it be a sync and then add the new change ? [20:25] sudip: I would prepare one upload that (a) drops the old changes, and (b) adds the new change. Just make all of this clear in the changelog/ [20:26] ack, thanks enr0n [20:26] no problem === dviererbe1 is now known as dviererbe