=== JanC_ is now known as JanC [10:03] Hello people, I am an Arch user, and I'm trying to build an app I made (gtk+python) for debian into a .deb file for debian and ubuntu. I have already a vm running ubuntu mate 17.10 and I verified that the app builds and runs. I am using the meson build system and I already have all the necessary debian specific files in place (compat, control, copyright, rules, soruce/format). I was wondering if there was a simple [10:03] meson to deb tutorial I could follow, and since I couldn't find anything on google, I'm asking here. any clue? thanks. [10:05] gabmus[m]: Newer debhelper supports meson buildsystem actually! [10:05] Unit193: please, tell me more [10:08] gabmus[m]: https://nthykier.wordpress.com/2017/06/26/debhelper-10-5-1-now-available-in-unstable/ basically, add meson to the build-depends. https://anonscm.debian.org/git/collab-maint/casync.git/tree/debian for example. [10:08] thanks, gonna have a look [10:09] Sure thing. [10:10] (Short of it, meson should work out of the box without any additional setup.) [10:13] cool, but I still don't get how to use debhelper. I'm a little bit spoiled by arch build system being so easy, I've got all the files I need in place already (copied from another project, thanks gpl) but don't know where to go next. for reference, here's the repo: https://github.com/gabmus/razercommander [10:14] * ogra_ would just create a snap instead ... runs on more distros, you are independent from the distro release and can update when you like ... [10:15] gabmus[m]: The aim is that your debian/rules doesn't need anything below line 10, as it's all done by line 9. https://github.com/GabMus/razerCommander/blob/master/debian/rules#L9 I am not awake enough to help, though. [10:15] not sure about snaps, but I'm pretty sure that once I get a deb file, the next thing will eb a flatpak [10:16] Faux: I'm pretty sure that lines below 10 won't hurt anyway, right? [10:24] http://paste.openstack.org/show/d9jqWbmh9I8IlBkT8UJq [10:30] Unit193: Awesome! thank you, will see where this goes [10:31] gabmus[m]: Your tarball didn't contain the meson build stuff, so untested. [10:31] what do you mean? [10:33] The tarball https://github.com/GabMus/razerCommander/releases [10:33] forget the releases, it's not up to date [10:33] clone master [10:33] will make an official release when I have the deb file ready [10:36] FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7. [10:37] http://paste.openstack.org/show/74A11xMBTTVKir03Sph4 on top of my last patch and you're set (well, clearly fix d/changelog and the description.) [10:39] gabmus[m]: Anywho, hope that helps ya out. I presume you know `dpkg-buildpackage` to build it an everything? [10:40] > FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7. [10:40] already fixed in local repo, gonna push soon [10:40] \o/ [10:43] I can't help you with snaps though, I tend to pretend they don't exist. [10:45] > I can't help you with snaps though, I tend to pretend they don't exist. [10:45] same here, won't bother about them for now [10:48] `dpkg-source: error: syntax error in razercommander/debian/control at line 29: block lacks the 'Package' field` [10:48] But it's there at line 17. any clue? [10:50] End of file is line 27, I presume you changed it? [10:51] nope [10:51] anyway, found the error, there was a newline he didn't like [10:55] OK.. [10:59] Unit193, you really shoudl give them a try unless you really love package maintenance (which you probably do since you are around in ubuntu nearly as long as i am :) ) ...creating a 30 line yaml file and 5 clicks in a webform to have every GH commit autobuild and release your stuff in a bunch of distros regardless of the release (without ever having to care again for the packaging) is really compelling ;) [10:59] wth is going on: http://termbin.com/7dwu [11:02] ogra_: I've been around as long as you? Oh dear, I'm not an old one! Eh, I don't use GH, and snaps just really aren't my thing. I do get how they're handy, perhaps a little too handy at times, but nevertheless. They shouldn't be the only option. :) [11:02] really, i thought you are around since ages :) [11:04] Eh, first started with Ubuntu in 2006/2007, didn't even fully move over until quite a bit later. [11:05] well, thats only 2 years less than i am around :) [11:05] gabmus[m]: 1. Malformed d/changelog, and two spaces before the date. Looks like a bad clean up too. [11:05] (and 10 years ... dude ! ... dont say your'e an old one ;) ) [11:05] *you're not [11:06] Nonono, that was first install! Not daily use! I dropped out for a while until 2010! [11:06] ...OK, I'm seeing your point. Fair enough. [11:06] :) [11:06] ...I'm old. :( [11:07] gabmus[m]: Basically, looks like the builddir wasn't removed. [11:08] dammt! I had a manually made builddir, that's what caused this [11:11] woah! it works! got a deb file along with many other files (.dsc, .build, .buildinfo, .changes) [11:11] and the deb installs and runs fine, that's awesome [11:12] \o/ [11:12] thank you Unit193 , your help has been invaluable to me [11:13] gabmus[m]: Sure thing, happy to help! [11:17] gabmus[m]: https://github.com/GabMus/razerCommander/blob/master/debian/control#L22 you generally want 'depends' under depends though. [11:18] tbh I don't know what those lines mean [11:19] 'debhelper' uses tools to figure out what the package depends on, in this case python3 3.4+ and adds that. [11:30] sladen: hi! could you please have a look at https://github.com/daltonmaag/ubuntu/pull/1? === NCommander is now known as mcasadevall === mcasadevall is now known as NCommander === NCommander is now known as mcasadevall === mcasadevall is now known as NCommander [11:57] madigens_: short answer, what we do with all th e manual hinting that was done [11:58] is that the main road blocker? [12:00] madigens_: a lot of the budget went on hinting. Things have moved on now (higher-DPI screens) and the requirement for manual hinting vs. eg. ttfautohint is less [12:00] (i personally would have no qualms just tossing it, but i guess that's not an option ;) ) [12:00] madigens_: however, it's a big mental block to effectively toss it [12:00] that i understand [12:01] i personally am not a fan of the way it was done -- it's as if daltonmaag tried to hint the font to diplay well on win95 [12:02] madigens_: the algorithm that idd the original cubic -> quatratic is proprietary (fontlab) so either we write some intelligent code that can do its best to replicate [12:02] madigens_: or we toss pretty much eeverything to do with hting and accept that [12:02] madigens_: as time goes on, the decision perhaps gets easier, but it's a hard pill to swallow [12:03] have there been discussions with dm on how to proceed? [12:03] madigens_: Dalton Maag did was needed and requested. Most Ubuntu Font users aren't using Ubuntu (OS)... [12:05] madigens_: and if you want to rener half decent on Windows/Cleartype then hinting is required. [12:05] render [12:05] i know, but given that most browsers aren't using GDI to render fonts anymore, a more ttfautohint-like approach (a "lightly" hinted font) would make more sense. i find the harsh hinting slightly dreadful on windows [12:05] madigens_: MacOSX/Quartz is less of an issue because it ignores most of the hinting [12:06] i'm not against hinting, i'm just a proponent of "light" hinting in the ttfautohint and adobe cff engine sense :) [12:06] madigens_: it also varies between the weights, different people worked on each [12:06] madigens_: yes, I concur, ttfautohint is the (ultimate) way to go [12:07] madigens_: we will have a zero-day at some point when it is moved to cubic + ttfautohint [12:07] madigens_: the question is when [12:07] additionally, the regular weight could be made slighly thinner ;) [12:07] madigens_: and how at that point to prove reasonable non-regression with the older cubic->qiuadratic->manually hinted outlines [12:08] so the typeface is still on the roadmap, good to hear. would be a shame to let it rot [12:08] madigens_: very happy to go over this more, and thank you for the poke. But it's the end of lunch and time to turn back into a train driver...! [12:09] is there a workgroup of sorts that moves these things forward? I'm asking because i'm working on cantarell (gnome default typeface) and would love to help with the other popular typeface :) [12:10] good luck! [17:29] Can a package in main have a dependency on package-in-main | package-in-universe? [17:32] mitya57: yes [17:32] (I believe) [17:32] mitya57: because that implies all necessary dependencies are satisfiable with just main === hyperair is now known as Guest76857 [17:41] nacc, thanks. I think I heard the opposite some time ago, but maybe that has been fixed since then. [17:49] mitya57: you might want someone with more experience than me to weigh in, to be sure; but I believe I have seen packages with that formulation [17:50] mitya57: e.g., i've also seen some with | where doesn't exist in Ubuntu [17:56] nacc, I have found an example of such a dependency in the same package I am working on (qtbase). [17:56] So yes, it seems to work ;) [17:57] mitya57: :) [18:05] tsimonq2, FYI I am building qtbase merge in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2969/+packages [18:06] Also FYI qtdeclarative will move to universe soon. [18:51] mitya57: ack [19:34] mitya57: I think the remaining reason qtbase is in main in artful is because ibus-mozc Recommends mozc-utils-gui in the live seed === milli` is now known as milli [20:51] jbicha, interesting [20:52] mitya57: On another Qt-related note, do you think it's worth it to look at releasing Qt 5.6.3 as an SRU in 16.04? [20:53] tsimonq2, of course no, 5.5 → 5.6 transition would break a lot of packages [20:53] mitya57: oh... I forgot Xenial was on 5.5 >_< [20:53] nvm, you're right [20:53] * tsimonq2 thought Xenial was on 5.6 and we could Just Update it [20:57] mitya57: that's at least the reason Qt is still on the artful iso. https://lists.ubuntu.com/archives/ubuntu-desktop/2017-September/005212.html [21:04] jbicha, actually it looks like there are more reverse dependencies: https://paste.ubuntu.com/25602299/ [21:04] Oh, snapd is a thing [21:04] Of course getting rid of Qt 5 on ISO is also a good task, as it would save some space. [21:07] mitya57: yes I saw that output but it's difficult to read. Some of those are only in main *because* qtbase is in main [21:07] some are already in http://people.canonical.com/~ubuntu-archive/component-mismatches.html at least [21:10] Oh right. [21:13] part of that is because of this section: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.artful/view/head:/supported#L315 [21:13] that's how libpoppler-qt5-dev is in main but I don't think it should be… [21:15] oh, qtubuntu is intentionally in main LP: #1708326 [21:15] Launchpad bug 1708326 in qtubuntu (Ubuntu) "RM: obsolete product" [Undecided,Invalid] https://launchpad.net/bugs/1708326 [21:17] Maybe it can be reconsidered if it turns out that it’s the only package keeping Qt in main? [21:18] I believe because Canonical ships qtubuntu as part of its kiosk products, it needs to be in main [21:18] is Qt being in main causing you problems? [21:19] No. [21:20] The only advantage for me of having it in universe would be that tsimonq2 will be able to upload it :) [21:20] he could probably apply for ppu for that [21:21] Right [21:22] * mitya57 → bed [21:35] * tsimonq2 looks into applying for PPU [23:48] anyone have any idea about this bug affecting both todays 32bit Ubuntu daily and Ubuntu Budgie 64bit daily? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1719136 [23:48] Launchpad bug 1719136 in ubiquity (Ubuntu) "Ubuntu and Ubuntu Budgie - there is no background picture on try/install" [Undecided,New] [23:49] odd - the 64bit Ubuntu daily is still stuck on the 19th Sept - no builds since then?