| tsimonq2 | In case nobody saw it yet: https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004438.html | 00:01 |
|---|---|---|
| Guest31513 | I'm downloading the image now to give it a try. Would like to investigate the hyper-v enhanced session functionality | 00:03 |
| === Guest31513 is now known as evancox10 | ||
| === sergiusens_ is now known as sergiusens | ||
| Laibsch | Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights? I have upload rights as PPU. Should I target bionic or bionic-proposed? | 07:05 |
| Laibsch | I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now. | 07:06 |
| Laibsch | I am trying to fix bug 1345605 | 07:07 |
| ubottu | bug 1345605 in fslint (Ubuntu) "error when searching bad symlinks" [Medium,In progress] https://launchpad.net/bugs/1345605 | 07:07 |
| Laibsch | BTW, the topic of the channel needs an update, doesn't it? | 07:07 |
| === tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 final beta released | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu | ||
| === tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 Final Beta released | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu | ||
| === tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 Final Beta released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu | ||
| tsimonq2 | There. | 07:10 |
| Laibsch | tsimonq2: Hi! In case you responded to me, I missed everything except the "There" due to internet outage. | 07:19 |
| tsimonq2 | I didn't. | 07:21 |
| tsimonq2 | :) | 07:21 |
| Laibsch | good, so I assume you just wanted to announce that you're back. | 07:24 |
| Laibsch | Welcome back! | 07:24 |
| Laibsch | I had posted a question that I will then assume that you missed and that I believe you might be able to answer. | 07:24 |
| tsimonq2 | Ah, looking. | 07:24 |
| Laibsch | Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights? I have upload rights as PPU. Should I target bionic or bionic-proposed? | 07:24 |
| Laibsch | I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now. I am trying to fix bug 1345605. BTW, the topic of the channel needs an update, doesn't it? | 07:24 |
| ubottu | bug 1345605 in fslint (Ubuntu) "error when searching bad symlinks" [High,In progress] https://launchpad.net/bugs/1345605 | 07:24 |
| tsimonq2 | Is it seeded? (hint: run `seeded-in-ubuntu $package`) | 07:25 |
| Laibsch | Oh, I see you just did the update of the channel tagline. | 07:25 |
| tsimonq2 | Yep. :) | 07:25 |
| Laibsch | I doubt it would be seeded, it is in universe | 07:25 |
| Laibsch | let me check | 07:25 |
| Laibsch | indeed, it is NOT seeded, so I can make the upload? | 07:27 |
| tsimonq2 | Yep, if it isn't seeded, Feature Freeze applies. | 07:27 |
| tsimonq2 | (Which is less strict.) | 07:27 |
| Laibsch | Yes, this only fixes a broken but current feature. | 07:28 |
| tsimonq2 | OK. | 07:28 |
| tsimonq2 | So, go ahead. :) | 07:28 |
| Laibsch | Thanks | 07:28 |
| Laibsch | Much appreciated | 07:28 |
| tsimonq2 | No problem. | 07:29 |
| tsimonq2 | And as to which you should target, target bionic. | 07:29 |
| Laibsch | good | 07:29 |
| tsimonq2 | The only time you include a pocket in the changelog is for -backports or -security. | 07:29 |
| tsimonq2 | It doesn't /hurt/ to target -proposed but it's just a tad bit weird. :) | 07:30 |
| Laibsch | well, the wiki says a bit otherwise. apparently, you're supposed to target -proposed for main now | 07:49 |
| Laibsch | https://wiki.ubuntu.com/FinalFreeze | 07:49 |
| tsimonq2 | That hasn't been edited since 2012. | 07:49 |
| Laibsch | Well, maybe it hasn't changed since then | 07:50 |
| tsimonq2 | Notably, before we implemented https://wiki.ubuntu.com/ProposedMigration | 07:50 |
| Laibsch | I wouldn't know the processes well enough | 07:50 |
| tsimonq2 | I know for a fact it has changed. ;) | 07:50 |
| Laibsch | good | 07:50 |
| Laibsch | I'm happy I can rely on your knowledge | 07:50 |
| tsimonq2 | Believe me when I say I've had to cut it close with some uploads. :P | 07:51 |
| Laibsch | One more question, am I correct to assume that binaries are thrown away after upload? | 07:51 |
| Laibsch | I'm used to Debian where I used to upload and then sync | 07:51 |
| tsimonq2 | You can only do source-only uploads to Ubuntu. | 07:52 |
| tsimonq2 | So syncs throw away binaries. | 07:52 |
| Laibsch | But what happens if you do include debs in your changes file and upload? | 07:53 |
| Laibsch | things break or the binaries simply get thrown away and rebuilt? | 07:54 |
| tsimonq2 | The upload will get rejected. | 07:54 |
| Laibsch | OK | 07:54 |
| tsimonq2 | cjwatson might have more specifics; I'm only an Ubuntu developer and don't have upload access to Debian (yet). :) | 07:54 |
| darkxst | tsimonq2, hi | 07:55 |
| tsimonq2 | darkxst: Hello, how are you? | 07:56 |
| darkxst | I am good | 07:56 |
| tsimonq2 | Good to hear, what's up? | 07:56 |
| darkxst | tsimonq2, just wondering if grasp the value in archive freezes, doesnt seem you do from your reply | 07:57 |
| tsimonq2 | I do understand the importance of them, but I disagree that they're still needed. | 07:58 |
| tsimonq2 | If flavors can just upload whatever they want and respin, you won't ever get a release, because flavors can just keep respinning. | 07:58 |
| tsimonq2 | Why even turn off the dailies? :) | 07:58 |
| tsimonq2 | The archive freezes are to create a stable image, true, but the day after, the fixes people have been holding off on get uploaded. | 07:59 |
| tsimonq2 | Thus, a stale image over that weekend. | 07:59 |
| darkxst | well flavours could just choose to leave the dailies on if they want | 08:00 |
| darkxst | but really having a semi-frozen archive where the flavours choose what to upload but universe etc is blocked out in general would allow you to make the most of your QA week | 08:00 |
| valorie | darkxst: can you say more about what you value in the freezes? | 08:00 |
| valorie | because I've not heard the release team argue for keeping them | 08:01 |
| tsimonq2 | darkxst: So, an inverted freeze? | 08:01 |
| tsimonq2 | That's an interesting idea. | 08:01 |
| darkxst | valorie, I am not release team, I was Ubuntu GNOME tech lead | 08:01 |
| valorie | that blocks the release team | 08:01 |
| valorie | yes, read your email just now | 08:02 |
| * valorie is the kub release manager and not so techy | 08:02 | |
| tsimonq2 | darkxst: Thinking about it though, the inverted freeze would just create a headache for non-flavor Ubuntu developers. | 08:02 |
| tsimonq2 | The goal here is to not require any intervention from ~ubuntu-release. | 08:03 |
| valorie | I get why we need deadlines for new features, string freezes, etc. | 08:03 |
| darkxst | valorie, assuming its on a similar schedule to previous milestones is that a problem | 08:03 |
| valorie | that's obvious | 08:03 |
| valorie | right, but I fail to see the value in freezing | 08:03 |
| tsimonq2 | Me too. | 08:04 |
| valorie | if you are testing and finding bugs, then the devels are fixing the bugs | 08:04 |
| valorie | then you can test those fixes right away | 08:04 |
| valorie | not wait until freeze is over | 08:04 |
| darkxst | valorie, if you don't freeze, other bugs may well creep in | 08:05 |
| valorie | but I want to hear the argument for what freezes bring | 08:05 |
| valorie | such as? | 08:05 |
| tsimonq2 | Right, but that's where testing comes in. | 08:05 |
| darkxst | valorie, you have a moving target, who knows what will change | 08:05 |
| valorie | well | 08:05 |
| tsimonq2 | darkxst: But that's the development release... | 08:06 |
| valorie | you are testing AN iso | 08:06 |
| darkxst | freezes give a point in time image, testers identify issues, the dev's can focus on fixing those issues | 08:06 |
| valorie | that's one moment in time | 08:06 |
| tsimonq2 | Right. | 08:06 |
| valorie | for this RC somehow kub. managed to test all the test cases | 08:06 |
| valorie | so respinning tomorrow would be cool | 08:07 |
| darkxst | the point the milestones become stale is after the release, not when they are released | 08:07 |
| valorie | because we could at least partially re-test | 08:07 |
| tsimonq2 | And often times, people report bugs after the release. | 08:07 |
| tsimonq2 | With the release ISO. | 08:07 |
| tsimonq2 | And they don't update. | 08:07 |
| tsimonq2 | That's a problem. | 08:07 |
| tsimonq2 | Much less so once you've entered a point where the archive is more stable. | 08:07 |
| darkxst | tsimonq2, even if you don't release milestone images, I think there is value in freezeing for your QA week (well days really) | 08:08 |
| valorie | I'm waiting to hear the advantages | 08:08 |
| valorie | can you give an example? | 08:08 |
| darkxst | valorie, I can;t give a real example, because its never been done before (unfrozen test weeks) | 08:09 |
| valorie | I meant a case where freezing was a benefit | 08:10 |
| valorie | all the people who test the dailies don't have freezes | 08:10 |
| valorie | although I don't have many DO that | 08:10 |
| valorie | I mean, I don't know how many do that | 08:10 |
| darkxst | and how much QA is done on the dailies? | 08:10 |
| alkisg | Freeze is a good signal for "everyone, please test now". I develop some packages and I want to test them 1-2 times for the new LTS Ubuntu version, but I can't test on a daily basis. | 08:11 |
| tsimonq2 | alkisg: But is that a technical argument or a social one? | 08:11 |
| valorie | we do have a few people who test a daily maybe one a week | 08:11 |
| tsimonq2 | The point of this is to not have the technical downsides while keeping the social benefits. | 08:11 |
| valorie | or when a devel asks | 08:11 |
| valorie | because they did a fix on the installer for instance | 08:12 |
| alkisg | I don't think it matter how I would categorize it; that's how much time I'm able to spend in helping/testing the newer Ubuntu; it's up to the release team to somehow tell me when they want me to do those tests | 08:12 |
| valorie | or something else easier to test on an ISO than in a ppa | 08:12 |
| valorie | alkisg: I think part of the point of this is to take that pressure off the release team, and have us flavors helping one another out | 08:13 |
| tsimonq2 | alkisg: Exactly. And if the Release Team said "test at this time" but didn't actually freeze anything, would that change things? | 08:13 |
| valorie | all getting together to do testing weeks | 08:13 |
| tsimonq2 | valorie: Exactly. | 08:13 |
| alkisg | tsimonq2: a new package upload might break other packages, making my tests useless | 08:13 |
| alkisg | So it would make sense for me to test at a point when the new uploads were minimal | 08:14 |
| alkisg | Now, minimal or frozen, no, it's not a big deal, but they should be minimal | 08:14 |
| valorie | I'm still not seeing your point | 08:14 |
| valorie | does it matter when this new package upload is made, if it is going to break your stuff? | 08:14 |
| valorie | I mean if you test before and everything's cool | 08:15 |
| valorie | and then the upload is made later, your stuff is broken..... | 08:15 |
| darkxst | valorie, often things break on upload, only to be fixed a few days later | 08:15 |
| darkxst | not you just wasted time debugging that breakage | 08:15 |
| darkxst | s/not/now/g | 08:15 |
| valorie | right, and that's why we shouldn't freeze! | 08:15 |
| valorie | lol | 08:15 |
| darkxst | which would have been fixed anyway | 08:16 |
| darkxst | rather than focusing on your flavours QA | 08:16 |
| alkisg | valorie: that's exactly my point, that that new upload that breaks stuff shouldn't be made. That's the point of the freeze, that only minor changes should be made after that, so that the big bulk of tests don't need to be done again | 08:16 |
| valorie | well, I think that is the point of doing the new auto-testing *first* | 08:16 |
| tsimonq2 | alkisg: Only seeded packages for some flavors are frozen. | 08:16 |
| valorie | so there are *never* uploads that break stuff | 08:17 |
| Laibsch | valorie: that's never going to happen | 08:17 |
| alkisg | You can't test how your packages affects other packages with unit testing; they may not even be installed at all when you're testing | 08:17 |
| Laibsch | autotests are nice, but "no bugs" is utopia | 08:17 |
| tsimonq2 | alkisg: I'm not saying we should get rid of the Final Beta freeze. I'm saying we should get rid of the freezes for just some flavors. | 08:17 |
| valorie | no, no | 08:17 |
| tsimonq2 | That's the point here. | 08:17 |
| darkxst | valorie, what I was suggesting was more let flavours upload bug fixes as required, but otherwise freeze the archive for the few days | 08:17 |
| valorie | software has bugs | 08:17 |
| valorie | ah | 08:18 |
| valorie | so imo that is probably what flavors would be doing anyway that week, right? | 08:18 |
| valorie | testing week is fixing bugs | 08:18 |
| alkisg | tsimonq2: I don't mind at all if it's complete freeze or partial freeze or just "advice for fewer uploads"; but as a developer/user that wants to help make things better, I do like having a specific point in time where "my tests have additional value, because from that point on, little changes are going to be made" | 08:18 |
| valorie | I dunno if we need a formal freeze | 08:19 |
| tsimonq2 | alkisg: The Alpha and Beta 1 freezes just aren't that. | 08:19 |
| tsimonq2 | alkisg: It's putting a name on a daily, really. | 08:19 |
| valorie | but I do see a value on Fixing Bugs | 08:19 |
| valorie | for a week | 08:19 |
| tsimonq2 | alkisg: You could grab any ISO from any point in the month and say "I'm going off of this" | 08:19 |
| tsimonq2 | alkisg: And with those freezes, changes can and will be made in the underlying stack, but just those flavors hold off. | 08:20 |
| tsimonq2 | alkisg: So this new procedure does just that. | 08:20 |
| darkxst | if there is no formal freeze, churn will continue | 08:21 |
| tsimonq2 | Churn continues regardless. | 08:21 |
| valorie | personally I would rather not block the release team | 08:21 |
| tsimonq2 | People just hold their breaths and then blast it at the archive once the freeze is done. | 08:21 |
| tsimonq2 | So why even freeze? | 08:21 |
| valorie | because it is hell to have major stuff still happening the last week of the cycle | 08:21 |
| darkxst | tsimonq2, because it you a specific point to focus on | 08:22 |
| darkxst | you can fix the bugs addressed, before more are raised | 08:22 |
| valorie | I think we are all stating positions here | 08:22 |
| valorie | rather than thinking together | 08:22 |
| darkxst | without having to worry about what else churns | 08:22 |
| valorie | we all want more quality | 08:22 |
| valorie | we all want fewer bugs | 08:22 |
| valorie | and we all want the shiny new stuff too | 08:23 |
| valorie | so what is the best way to get there? | 08:23 |
| valorie | we have only 6 months to make each batch of sausage | 08:23 |
| * alkisg sees little value in the non-LTS releases, but that's another story :D | 08:24 | |
| valorie | really? | 08:24 |
| valorie | I do not like to be on stale anything | 08:24 |
| tsimonq2 | darkxst: The only bugs fixed during that time are release-critical ones. Not just plain old bugfixes. So I still think it's pointless. | 08:24 |
| alkisg | Yeah, I would much prefer having only LTS releases, and some method for package maintainers to more easily push new versions of their packages to LTS releases | 08:24 |
| valorie | I ran artful from the day the toolchain was uploaded | 08:24 |
| valorie | alkisg: that removes the value of LTS | 08:25 |
| valorie | imo | 08:25 |
| alkisg | I think it adds additional value | 08:25 |
| alkisg | I'm hearing a lot of users that would prefer newer versions of *some* packages in LTS releases | 08:25 |
| darkxst | tsimonq2, which is way I was saying to relax it a bit | 08:25 |
| valorie | well, there is always backports | 08:25 |
| valorie | that is what kub provides | 08:26 |
| tsimonq2 | Regardless of the talk we're having right now, I've received ACKs from everyone with skin in the game. So I think it's worth trying, at least for a cycle. We can tweak it as we go, and as we see how it turns out. | 08:26 |
| alkisg | Indeed; but backports aren't used as much as they should... | 08:26 |
| valorie | I dunno if our users use them enough, but I often urge them to try them out | 08:26 |
| valorie | because if it doesn't work out, ppa-purge is your friend | 08:27 |
| alkisg | Backports aren't in ppas | 08:27 |
| alkisg | They're in the official archive | 08:27 |
| valorie | we test those too | 08:27 |
| darkxst | tsimonq2, valorie, I was only only offering my thoughts based on 5 years of releasing Ubuntu GNOME milestones, I have no vested interest in the outcome of these discussion, but if you are all going to be so defensive I will just get on with the others thing I need to get done | 08:27 |
| valorie | in Kubuntu, we have a backport PPA | 08:27 |
| alkisg | valorie: that's usually a bad idea, mate does that too and I hate it | 08:28 |
| valorie | no, I wanted to hear your reasons | 08:28 |
| alkisg | It would make a lot more sense to use backports there, rather than a PPA | 08:28 |
| valorie | I just didn't hear reasons | 08:28 |
| valorie | or examples | 08:28 |
| tsimonq2 | darkxst: I'm not being defensive, I just see the idea being shot down before there's a chance to try it, that's all. | 08:28 |
| tsimonq2 | s/being/trying to be/ | 08:29 |
| valorie | I know that Simon didn't develop the idea alone; he discusses pros and cons with quite a few people (not me) before making the proposal | 08:30 |
| valorie | I spoke only after the release team said that they supported it, because to me that is the most important opinion | 08:31 |
| darkxst | tsimonq2, shot down by who? | 08:33 |
| tsimonq2 | darkxst: Maybe I'm using the term liberally, but this discussion is happening as a result of making it official. | 08:35 |
| tsimonq2 | (It seems like it, anyway.) | 08:35 |
| tsimonq2 | I gave a good three weeks between the discussion and doing so. | 08:35 |
| darkxst | tsimonq2, no this has nothing to do with that, just I didnt get a chance to comment earlier | 08:36 |
| valorie | I'm glad to hear differing opinions | 08:36 |
| darkxst | again I have no vested interest in the result | 08:36 |
| valorie | just wish they had been stated earlier | 08:36 |
| valorie | groupthink can be an issue when people don't push back when they have reservations about a new idea | 08:37 |
| darkxst | valorie, unfortunately I have full-time job unrelated to ubuntu, which makes me kind of busy | 08:37 |
| valorie | yeah | 08:37 |
| valorie | anyway, creeping carrot will be a non-LTS | 08:38 |
| valorie | so if it doesn't work out well, we have time to revert to milestones and freezes, or modify slightly | 08:39 |
| tsimonq2 | *Calculating Camel | 08:39 |
| tsimonq2 | And, right. | 08:39 |
| darkxst | freezes are useful even if there is not an official milestone image to come out of it! | 08:43 |
| valorie | well, the lack of them might prove you right, darkxst | 08:44 |
| Laibsch | What do you guys use to prepare the changes file to upload? For uploads to Debian (that requires binaries to be included) I used to use pbuilder and now cowbuilder. But now I need a source-only changes file and haven't quite figured out yet how to do that. | 09:30 |
| Laibsch | I only build in a chroot like pbuilder, my main machine has very few if any dev-packages installed. | 09:31 |
| Laibsch | answering for myself, looks like it might be as easy as "dpkg-genchanges" even if the manpage says the source needs to have been built which outside of the chroot it hasn't been. | 09:40 |
| darkxst | Laibsch, sbuild | 09:43 |
| Laibsch | darkxst: thanks, I will look into. Never used it so far and never had to. | 09:44 |
| Laibsch | "debuild -S -d" or even simply "dpkg-buildpackage -S -d" (AFAIU, debuild calls dpkg-buildpackage) | 09:45 |
| darkxst | Laibsch, see sbuild-launchpad-chroot it produces almost identical environment to the Ubunutu archive and PPA builders | 09:45 |
| darkxst | Laibsch, and in chroot, so your not mutating your package sources | 09:46 |
| Laibsch | dpkg-buildpackage seems to do it | 09:46 |
| darkxst | you can also bootstrap debian into sbuild quite easily | 09:46 |
| Laibsch | well, same is true for pbuilder and I'm more familiar with that | 09:46 |
| Laibsch | but in the end, I think it seems to be necessary for Debian since you need to actually build the code and ship the binaries, the requirements for Ubuntu infrastructure apparently are already fulfilled by a lower-level tool like dpkg-buildpackage | 09:47 |
| darkxst | Laibsch, are you uploading to ubuntu? | 09:48 |
| Laibsch | yes | 09:48 |
| darkxst | then use sbuild-launchpad-chroot | 09:48 |
| darkxst | to test | 09:49 |
| Laibsch | test what? | 09:49 |
| cjwatson | debuild -S or any near-enough equivalent is fine, indeed. Just building a source package doesn't usually need much in the way of build-deps. | 09:49 |
| darkxst | package builds, before uploading | 09:49 |
| Laibsch | thanks for confirming, cjwatson | 09:49 |
| Laibsch | darkxst: I already built and started the package | 09:49 |
| cjwatson | And indeed, tsimonq2 is correct, if you attempt to include .debs with an upload it will be summarily rejected. | 09:49 |
| Laibsch | cjwatson: I tried ;-) | 09:49 |
| Laibsch | or actually, what I tried was to fiddle with the changes file, remove the lines for the binary files so they would not be uploaded but it was still rejected (I assume because the changes file name had "amd64" in it, indicating an arch-dependent build) | 09:51 |
| cjwatson | Editing .changes manually is fiddly. Not recommended. | 09:51 |
| Laibsch | I know | 09:51 |
| cjwatson | And for Debian nowadays you should really do source-only uploads too, except in unusual circumstances. | 09:51 |
| Laibsch | First attempt | 09:51 |
| Laibsch | really? | 09:51 |
| Laibsch | didn't know | 09:51 |
| cjwatson | Really. | 09:51 |
| Laibsch | Well, no more uploads to debian for me anyhow. | 09:52 |
| tsimonq2 | cjwatson: When can we have source-only NEW in Debian? :P | 09:52 |
| * tsimonq2 wishes for that. | 09:53 | |
| Laibsch | looks like the upload was successful and accepted | 09:53 |
| cjwatson | tsimonq2: Do I look like a Debian ftpmaster? | 10:03 |
| acheronuk | kirkland: byobu no longer shows a ubuntu logo in bionic? | 10:04 |
| tsimonq2 | cjwatson: I was joking there. :P | 10:06 |
| tsimonq2 | Right, time for bed. | 10:06 |
| Laibsch | tsimonq2: are you in Hawaii or something? | 10:07 |
| tsimonq2 | No, Wisconsin. | 10:09 |
| Laibsch | ouch | 10:30 |
| Laibsch | interesting time to go to sleep ;-) | 10:30 |
| Laibsch | happy Zzz | 10:30 |
| === sergiusens_ is now known as sergiusens | ||
| === tomreyn_ is now known as tomreyn | ||
| === realies- is now known as realies | ||
| realies | the novnc package is missing its launch script, any clues why? | 16:28 |
| realies | https://github.com/novnc/noVNC/blob/master/utils/launch.sh | 16:31 |
| realies | ^ | 16:31 |
| realies | also is very old, the newer releases have great improvements | 16:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!