| BluesKaj | Hi all | 11:50 |
|---|---|---|
| santa_ | hi everyone | 17:16 |
| santa_ | tsimonq2: ping - your pkg-kde-tools debian merge works fine, last weekend I have seen everything of fw, plasma, apps builds fine against it | 17:18 |
| santa_ | so please go ahead and put the changes in git | 17:18 |
| santa_ | also an upload in the begining of the oracular archive opening would be nice | 17:19 |
| santa_ | and ... | 17:19 |
| tsimonq2 | ack will do, endorsing someone for MOTU right now, will get to this right after | 17:19 |
| santa_ | RikMills, sgmoore, tsimonq2: misc news from my front just FYI: | 17:20 |
| santa_ | - I have been preparing to update my test build servers for oracular: area51 done, pending: watertown, groomlake | 17:21 |
| santa_ | - KA 2.6 released, already set up for oracular | 17:22 |
| santa_ | - KA metadata initialized for oracular | 17:22 |
| santa_ | - kubuntu_oracular_archive and kubuntu_oracular_staging branches created for fw/plasma/apps | 17:22 |
| santa_ | - at some point I would start with KA 2.7; hot potatoes: orig tarball repack support, kf6 support | 17:23 |
| santa_ | - this weekend I would like to take care of the kf5 release so I can test latest things from KA (but I expect it to work fine) | 17:25 |
| santa_ | and I think that's it for now | 17:26 |
| tsimonq2 | oh there's another KF5 release? | 17:26 |
| santa_ | yes, we would have the pre-release tarballs this weekend https://community.kde.org/Schedules/Frameworks | 17:27 |
| tsimonq2 | hmmm what's new? | 17:27 |
| santa_ | bugfixes mostly I guess | 17:28 |
| tsimonq2 | anything that should target noble you think? | 17:28 |
| santa_ | KF5 will continue to be in use for a while so makes sense | 17:29 |
| santa_ | tsimonq2: we usually do backports and that's it | 17:30 |
| tsimonq2 | this is true, but we're almost at kf5 EOL anyway | 17:30 |
| tsimonq2 | may make sense to evaluate whether we can SRU just this time | 17:30 |
| santa_ | we don't usually do it because that's a lot of 'paperwork' | 17:32 |
| santa_ | also propably this is not going to be the last release of KF5 | 17:32 |
| santa_ | meaning we would have to do further SRUs | 17:32 |
| santa_ | (if we want to put the latest) | 17:33 |
| santa_ | but well, let's see once we have it packaged | 17:36 |
| tsimonq2 | ok :) | 17:43 |
| tsimonq2 | santa_: https://launchpad.net/ubuntu/+source/pkg-kde-tools/0.17.1ubuntu1 | 18:01 |
| santa_ | ah, the archive is open already? | 18:03 |
| tsimonq2 | yes :) | 18:03 |
| tsimonq2 | someone must have forgotten an email :/ | 18:03 |
| santa_ | thanks for the upload | 18:03 |
| tsimonq2 | no worries | 18:03 |
| santa_ | since when is open? | 18:03 |
| tsimonq2 | maybe a day or two? not sure | 18:03 |
| tsimonq2 | not long | 18:03 |
| santa_ | yeah must have been this week | 18:04 |
| santa_ | I was expecting that mail in -announce | 18:04 |
| tsimonq2 | santa_: btw https://pad.riseup.net/p/uUGH3GQsHLZz1--651Kk-keep | 18:04 |
| santa_ | thanks | 18:06 |
| tsimonq2 | no problem | 18:07 |
| santa_ | ugh+ | 18:07 |
| santa_ | "and sync all source packages to Ubuntu" | 18:07 |
| santa_ | please don't | 18:07 |
| tsimonq2 | we will have to | 18:07 |
| tsimonq2 | why not? | 18:08 |
| santa_ | for the same reasons we don't do it with kf5 | 18:08 |
| santa_ | we can prepare the packages in a staging PPA first, then upload | 18:09 |
| tsimonq2 | less friction with this much source NEW to do it from Debian first, then we can diverge | 18:09 |
| tsimonq2 | AAs will not like 70 something Ubuntu-native source NEW packages | 18:09 |
| tsimonq2 | so I think we should rehash the "why do we have a kf5 delta again?" debate | 18:10 |
| santa_ | no | 18:10 |
| tsimonq2 | ok so then do we have the reasons documented somewhere? | 18:11 |
| tsimonq2 | because otherwise we'll be moving forward without it | 18:11 |
| santa_ | we don't have it documented but syncing kde packages from debian is simply a bad strategy | 18:12 |
| tsimonq2 | we have two Debian Developers on the team now | 18:12 |
| tsimonq2 | if we want to diverge at a later point we casn | 18:12 |
| tsimonq2 | but not immediately when it's a bunch of NEW | 18:12 |
| santa_ | I undestand the idea of doing it as an initial step, in that case it's not so bad, but it's still bad without reviewving some things in the package | 18:13 |
| tsimonq2 | so let's start the review process | 18:13 |
| santa_ | I have already seen a serious violation of the debian policy | 18:13 |
| tsimonq2 | where? let's get it fixed | 18:13 |
| santa_ | I intend to do this at some point, so please give me some time to review properly | 18:14 |
| tsimonq2 | ok, please let me know when we have a list, I will help follow up with Debian | 18:14 |
| tsimonq2 | sgmoore: ^ | 18:15 |
| santa_ | besides, syncing all of this without having KA and our infra prepared is just starting the house by the roof | 18:15 |
| tsimonq2 | it means nothing until we actually switch Plasma over to it, at which point I could see automation being fully set | 18:16 |
| santa_ | I mean we will need to track the build status, we will probably need to update symbols files, etc. | 18:16 |
| Eickmeyer | Yeah, no. We should be syncing from Debian *where possible*. "No" is not a good reason. Please spell out the reason. | 18:23 |
| Eickmeyer | Violation of the Deiban policy? Cool, we can fix it upstream. Two DDs on the team. | 18:25 |
| Eickmeyer | Saves a ton of work here. | 18:25 |
| Eickmeyer | So, where's the rational argument? | 18:26 |
| santa_ | Eickmeyer: how many frameworks releases have you packaged? (just asking) | 18:30 |
| Eickmeyer | santa_: Irrellevant and doesn't answer my question. | 18:31 |
| santa_ | Eickmeyer: not irrelevant, and you didn't answer my question either | 18:32 |
| Eickmeyer | santa_: I asked first. Please. | 18:32 |
| santa_ | Eickmeyer: we will see with time, but if you don't have experience packaging frameworks, how can you have an opinion about what should be done? | 18:33 |
| Eickmeyer | santa_: Because if you simply sync from Debian, then you don't have to. | 18:34 |
| santa_ | Eickmeyer: have you tried that any time? | 18:35 |
| Eickmeyer | Heh, I could do a `syncpackage` right now and do it, but I won't. | 18:35 |
| Eickmeyer | I'd rather coordinate and be a team player. | 18:36 |
| santa_ | thaks, like I said, we will see with time :) | 18:36 |
| Eickmeyer | Either way, the Plasma 6 transition / Qt6 transtition is happening with or without KA. Has to happen. Full stop. | 18:37 |
| Eickmeyer | Whether you choose to be a part of it is up to you. | 18:37 |
| santa_ | s/thaks/thanks/ | 18:38 |
| Eickmeyer | I knew what you meant. :) | 18:38 |
| santa_ | of course the transition will happen, but better if it goes the proper way | 18:39 |
| santa_ | we will see the issues one by one | 18:39 |
| santa_ | also, maintaining kde packages without automation is not feasible | 18:40 |
| Eickmeyer | That's your opinion. | 18:40 |
| santa_ | i.e. it's an important part of the mix | 18:40 |
| Eickmeyer | I trust people like sgmoore and tsimonq2 . | 18:40 |
| santa_ | no, it's not an opinion Eickmeyer, it's a fact | 18:40 |
| Eickmeyer | But KA cannot hold the transition hostage. | 18:40 |
| santa_ | KA is not going to hold anything hostage | 18:41 |
| Eickmeyer | It will not be a blocker. It will procede with or without. That's me with my Ubuntu Studio lead hat on. | 18:41 |
| santa_ | you seem to be so sure about your opinions about technical issues where you don't have experience | 18:41 |
| Eickmeyer | You seem to be sure I don't have experience. | 18:41 |
| santa_ | that's not a good path in somoneone's life, but it's your life | 18:42 |
| Eickmeyer | And making broad assumptions about me. | 18:42 |
| Eickmeyer | CoC: Assume good intentions. | 18:42 |
| santa_ | I'm not assuming bad intentions, I'm assuming good intentions | 18:42 |
| Eickmeyer | Then assume that KA isn't the be-all-end-all just because you happened to write it. :) | 18:43 |
| Eickmeyer | Humans will make mistakes, and we will learn. | 18:43 |
| santa_ | it's the oposite | 18:44 |
| santa_ | I don't think that KA is important because I wrote a significant part of the code, it's the oposite | 18:44 |
| santa_ | I worked on it because it's important | 18:44 |
| santa_ | it's not feasible to deal with hundreds of packages without good tools | 18:45 |
| santa_ | it would take an eternity to do things manually | 18:45 |
| Eickmeyer | Ok, but do me a favor: don't gatekeep me because you think I'm inexperienced. You just did that (again) and broke the CoC in the process. | 18:45 |
| santa_ | I don't gatekeep anything, and I'm not breaking any CoC I'm just talking to you, nothing more | 18:46 |
| Eickmeyer | "how many frameworks releases have you packaged? (just asking)" > leading question about experience. You should never do that when people are volunteering. From the CoC: "We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates | 18:49 |
| Eickmeyer | the required capacity and competence." I'm a MOTU, so I've already demonstrated to the DMB my competence. | 18:49 |
| arraybolt3 | santa_, Eickmeyer: ok both of you, calm down. This is a needless fight that isn't going to move anything forward and may delay things. | 18:49 |
| arraybolt3 | We will get KF6 packages however is going to work best for 24.10, and I'm sure we can find a way that we agree on for how to do it. Slapping each other with "who has more experience" isn't helpful. | 18:50 |
| Eickmeyer | arraybolt3: Agreed. I didn't want it to go down that road. | 18:50 |
| arraybolt3 | I get why the idea of syncing from Debian seems attractive, since it will probably give us a great speed boost. I also see why it could be disastrous because I had to clean up the wreakage after an LXQt sync from Debian some cycles ago and it was Not Fun(TM). If there are dragons that will bite us if we sync, we need to figure out how to either not sync or how to work around the dragons. If | 18:51 |
| arraybolt3 | we can sync safely, I'm all for it, but only if we can do it safely. | 18:52 |
| santa_ | Eickmeyer: I'm not saying you are not welcome to contribute or anything like that, however, when someone doesn't have experience with something - in this case packaging kde frameworks - that someone may have wrong opinions | 18:52 |
| santa_ | that's what I'm trying to explain to you | 18:53 |
| Eickmeyer | santa_: And I don't get where you're getting that assumption. Ubuntu Studio literally uses KDE Frameworks. I know how it's packaged. I understand KA. I'm saying it might be unnecessary. | 18:54 |
| santa_ | but we will see the issues with time, as long as you are open to learn; if you think that you already know everything because you are MOTU and Ubuntu Studio uses KDE, then we are not going anywhere | 18:55 |
| arraybolt3 | I also don't see how saying "it might be unnecessary" is helpful. Eickmeyer, as much as you want santa_ to give concrete examples of why it won't work, it might serve everyone well if you provide concrete examples of why you think it will work. How close is KF5 packaging in Kubuntu to KF5 packaging in Debian, and how much work do you think it will be to Ubuntu-ize the Debian packages vs. | 18:56 |
| arraybolt3 | continuing to maintain it separately? | 18:56 |
| Eickmeyer | arraybolt3: tsimonq2's idea, not mine. | 18:56 |
| * arraybolt3 throws up his hands | 18:58 | |
| arraybolt3 | this still isn't anything more than an "uh-huh", "nuh-uh" argument, on both sides. Not everything tsimonq2 thinks of is a great idea, not everything Eickmeyer thinks of is a good idea, not everything santa_ thinks of is a good idea, and not everything I think of is a good idea. Debating over experience when we're all highly experienced here is not going to help anything. | 18:59 |
| Eickmeyer | That said, I support the idea of syncing from Debian. Less work for all of us. | 19:02 |
| Eickmeyer | Time to put KA out to pasture and *actually work* with Debian. | 19:02 |
| Eickmeyer | They have a system already, might as well work with it instead of duplicating effort. | 19:03 |
| santa_ | Eickmeyer: again, if you never packaged frameworks, how can you be so sure your opinion is correct? | 19:06 |
| Eickmeyer | santa_: If it's already packaged, why duplicate the effort? | 19:06 |
| tsimonq2 | arraybolt3, santa_, Eickmeyer: Kay, let's clear up some misunderstandings... the entire reason we're syncing from Debian on this is because they're entirely new source packages. The archive administrators in Ubuntu will handwave packages from Debian, but if we decide *not* to sync and just upload all the source NEW packages ourselves, we're costing both us and the AAs valuable time because they | 19:09 |
| tsimonq2 | will *have* to do a re-review. We're shifting the responsibility from Debian to us when it comes to source NEW, which isn't really feasible. It will have no reverse dependencies to start, so we can always run tooling after it's all accepted. The plan is *not* to *keep* these packages in sync with Debian, only to do the *initial* source NEW reviews via Debian syncs instead of uploading ourselves. | 19:09 |
| santa_ | Eickmeyer: we are not duplicating anything, we reuse the work from debian as much as possible, however we need to verify some things | 19:09 |
| tsimonq2 | We don't need to verify anything *before* it gets through source NEW as long as it builds. | 19:09 |
| tsimonq2 | Debian has done that work for us. | 19:10 |
| santa_ | tsimonq2: I'm not oposed to your idea as long as we check/fix some things first | 19:10 |
| tsimonq2 | We can patch specific packages and send those upstream, but doing it all ourselves isn't feasible. It's duplicating work. | 19:10 |
| tsimonq2 | santa_: The sync will happen whether the checks are done in time or not. The real deadline here is release day. | 19:10 |
| tsimonq2 | We are *not* at the point of moving Plasma over yet. | 19:10 |
| tsimonq2 | We have time. | 19:10 |
| tsimonq2 | Therefore, let's just do the syncs from Debian and deal with those things *after* the most friction-ful part is done. | 19:11 |
| tsimonq2 | Which is the NEW queue. | 19:11 |
| santa_ | one thing I wanted to do is building the packages from debian's git, see what needs to be fixed | 19:11 |
| tsimonq2 | I completely agree, but we're not hard-blocking on it. | 19:12 |
| tsimonq2 | We *should* run automation, but the hesitation around syncing from Debian is pointless. | 19:12 |
| santa_ | https://salsa.debian.org/qt-kde-team/kde/kf6-kwindowsystem/-/blob/debian/experimental/debian/libkf6windowsystem6.install?ref_type=heads | 19:13 |
| RikMills | Hi. I have to agree with tsimonq2 on this. Initial sync from debian, then review the process from there. Considering toolchain/builder differences, maintaining a delta on many packages is likely | 19:13 |
| santa_ | ↑ I found it, this is probably a violation of https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#shared-library-support-files | 19:14 |
| RikMills | Plus at man y pointes we will still have to package considerably ahead of debian | 19:14 |
| tsimonq2 | RikMills: +1 | 19:14 |
| RikMills | Without KA that is not viable | 19:14 |
| santa_ | please see the thing I have pointed above | 19:15 |
| tsimonq2 | santa_: Well, Debian's AAs accepted it. I think you're probably right re: policy, but we have plenty of time to deal with it, after it's synced, and before we switch rdeps of KF5 over. | 19:15 |
| RikMills | As stressed, there is time. | 19:15 |
| santa_ | tsimonq2: sure, but please keep in mind fixing that means creating a separate binary package providing usr/lib/*/qt6/plugins/kf6/kwindowsystem/ | 19:16 |
| santa_ | meaning the fix would have to go through ubuntu's upload queue | 19:16 |
| tsimonq2 | santa_: I know; binary NEW is a lot easier than source NEW | 19:17 |
| tsimonq2 | Plus, that should be filed as a Debian bug | 19:17 |
| santa_ | so I think it's better to do at least a quick review of the things in debian before syncing | 19:17 |
| tsimonq2 | Go ahead and do the review if you'd like, we aren't blocking on it | 19:18 |
| santa_ | ok, give me the next few days | 19:18 |
| arraybolt3 | santa_: looking | 19:18 |
| arraybolt3 | oh I'm not scrolled down far enough | 19:18 |
| santa_ | in fact I already started to review things | 19:18 |
| santa_ | it wasn't my intention to discuss it today | 19:18 |
| santa_ | ... but things poped up, so: | 19:19 |
| tsimonq2 | santa_: Uh, it'll take at least another week or two for Qt to clear :P | 19:20 |
| santa_ | one thing I have been testing is extra-cmake-modules | 19:20 |
| santa_ | in debian, they have created all the repos for kf6 with the kf6- prefix | 19:20 |
| santa_ | both for the git repo name and the source package | 19:21 |
| santa_ | except extra-cmake-modules | 19:21 |
| santa_ | they just uploaded 6.x with the same source package name | 19:22 |
| RikMills | IIRC that should be compatible with KF5 and KF6, so not need to have a new repo or source package | 19:22 |
| RikMills | but that is just what I have read.... | 19:23 |
| santa_ | yes, and that means, if this e-c-m is synced into Ubuntu the kf5 version is going to die | 19:23 |
| tsimonq2 | Okay, so we just keep things in -proposed for a little bit... | 19:23 |
| RikMills | I mean that current KF5 should build with the new ecm | 19:23 |
| RikMills | But yes, test that | 19:24 |
| santa_ | ... so one thing that I tested in one of my servers is rebuilding all of fw5/plasma5/apps5 with this new ecm | 19:24 |
| santa_ | everything was built successfully | 19:24 |
| santa_ | meaning the way they managed e-c-m in debian shoudln't be a problem | 19:25 |
| RikMills | ok :) | 19:26 |
| santa_ | I mean, I'm not oposed to do a sync from debian to get *initially* the packages @ ubuntu archive | 19:28 |
| santa_ | but we need to check these kind of things first, don't you think? :D | 19:28 |
| santa_ | imagine they screwed up the thing in debian and actually it should be done with the kf6- prefix: | 19:29 |
| santa_ | - no problem for them because it's in experimental | 19:30 |
| santa_ | - we are in a situation in ubuntu | 19:30 |
| santa_ | so... better to check these kind of things | 19:31 |
| santa_ | btw the violation of debian policy 8.2 has been a trend for some years | 19:31 |
| santa_ | let's see if it stops once and for all | 19:32 |
| santa_ | anyway, I'm going to have dinner | 19:34 |
| santa_ | have a good night everyone | 19:34 |
| tsimonq2 | santa_: have a good dinner :) | 19:35 |
| tsimonq2 | let's start a running list | 19:35 |
| tsimonq2 | Fix in Ubuntu first, then send up to Debian and get it fixed there | 19:35 |
| santa_ | I forgot to mention: please consider the fact that a number of packages could FTBFS in ubuntu because of symbols files | 19:36 |
| RikMills | that is one of the thing I meant by toolchain etc differences | 19:37 |
| RikMills | santa_: thanks. have a good night | 19:38 |
| santa_ | yeah sure, but I mean, it would be convenient to have the things from KA ready to track the build failures (i.e. ka-iron-hand + ppa-build-status) | 19:39 |
| santa_ | anyway, good night, now for real :D | 19:41 |
| santa_ | see you tomorrow | 19:41 |
| === guiverc2 is now known as guiverc | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!