[10:03] <gabmus[m]> 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] <gabmus[m]> 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] <Unit193> gabmus[m]: Newer debhelper supports meson buildsystem actually!
[10:05] <gabmus[m]> Unit193: please, tell me more
[10:08] <Unit193> 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] <gabmus[m]> thanks, gonna have a look
[10:09] <Unit193> Sure thing.
[10:10] <Unit193> (Short of it, meson should work out of the box without any additional setup.)
[10:13] <gabmus[m]> 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] <Faux> 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] <gabmus[m]> 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] <gabmus[m]> Faux: I'm pretty sure that lines below 10 won't hurt anyway, right?
[10:24] <Unit193> http://paste.openstack.org/show/d9jqWbmh9I8IlBkT8UJq
[10:30] <gabmus[m]> Unit193: Awesome! thank you, will see where this goes
[10:31] <Unit193> gabmus[m]: Your tarball didn't contain the meson build stuff, so untested.
[10:31] <gabmus[m]> what do you mean?
[10:33] <Unit193> The tarball https://github.com/GabMus/razerCommander/releases
[10:33] <gabmus[m]> forget the releases, it's not up to date
[10:33] <gabmus[m]> clone master
[10:33] <gabmus[m]> will make an official release when I have the deb file ready
[10:36] <Unit193> FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7.
[10:37] <Unit193> 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] <Unit193> gabmus[m]: Anywho, hope that helps ya out.  I presume you know  `dpkg-buildpackage` to build it an everything?
[10:40] <gabmus[m]> > FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7.
[10:40] <gabmus[m]> already fixed in local repo, gonna push soon
[10:40] <Unit193> \o/
[10:43] <Unit193> I can't help you with snaps though, I tend to pretend they don't exist.
[10:45] <gabmus[m]> > I can't help you with snaps though, I tend to pretend they don't exist.
[10:45] <gabmus[m]> same here, won't bother about them for now
[10:48] <gabmus[m]> `dpkg-source: error: syntax error in razercommander/debian/control at line 29: block lacks the 'Package' field`
[10:48] <gabmus[m]> But it's there at line 17. any clue?
[10:50] <Unit193> End of file is line 27, I presume you changed it?
[10:51] <gabmus[m]> nope
[10:51] <gabmus[m]> anyway, found the error, there was a newline he didn't like
[10:55] <Unit193> OK..
[10:59] <ogra_> 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] <gabmus[m]> wth is going on: http://termbin.com/7dwu
[11:02] <Unit193> 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] <ogra_> really, i thought you are around since ages :)
[11:04] <Unit193> Eh, first started with Ubuntu in 2006/2007, didn't even fully move over until quite a bit later.
[11:05] <ogra_> well, thats only 2 years less than i am around :)
[11:05] <Unit193> gabmus[m]: 1. Malformed d/changelog, <email@domain.tld> and two spaces before the date.  Looks like a bad clean up too.
[11:05] <ogra_> (and 10 years ... dude ! ... dont say your'e an old one ;) )
[11:05] <ogra_> *you're not
[11:06] <Unit193> Nonono, that was first install!  Not daily use!  I dropped out for a while until 2010!
[11:06] <Unit193> ...OK, I'm seeing your point.  Fair enough.
[11:06] <ogra_> :)
[11:06] <Unit193> ...I'm old. :(
[11:07] <Unit193> gabmus[m]: Basically, looks like the builddir wasn't removed.
[11:08] <gabmus[m]> dammt! I had a manually made builddir, that's what caused this
[11:11] <gabmus[m]> woah! it works! got a deb file along with many other files (.dsc, .build, .buildinfo, .changes)
[11:11] <gabmus[m]> and the deb installs and runs fine, that's awesome
[11:12] <Unit193> \o/
[11:12] <gabmus[m]> thank you Unit193 , your help has been invaluable to me
[11:13] <Unit193> gabmus[m]: Sure thing, happy to help!
[11:17] <Unit193> gabmus[m]: https://github.com/GabMus/razerCommander/blob/master/debian/control#L22 you generally want 'depends' under depends though.
[11:18] <gabmus[m]> tbh I don't know what those lines mean
[11:19] <Unit193> 'debhelper' uses tools to figure out what the package depends on, in this case python3 3.4+ and adds that.
[11:30] <madigens_> sladen: hi! could you please have a look at https://github.com/daltonmaag/ubuntu/pull/1?
[11:57] <sladen> madigens_: short answer, what we do with all th e manual hinting that was done
[11:58] <madigens_> is that the main road blocker?
[12:00] <sladen> 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] <madigens_> (i personally would have no qualms just tossing it, but i guess that's not an option ;) )
[12:00] <sladen> madigens_: however, it's a big mental block to effectively toss it
[12:00] <madigens_> that i understand
[12:01] <madigens_> 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] <sladen> 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] <sladen> madigens_: or we toss pretty much eeverything to do with hting and accept that
[12:02] <sladen> madigens_: as time goes on, the decision perhaps gets easier, but it's a hard pill to swallow
[12:03] <madigens_> have there been discussions with dm on how to proceed?
[12:03] <sladen> madigens_: Dalton Maag did was needed and requested.  Most Ubuntu Font users aren't using Ubuntu (OS)...
[12:05] <sladen> madigens_: and if you want to rener half decent on Windows/Cleartype then hinting is required.
[12:05] <sladen> render
[12:05] <madigens_> 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] <sladen> madigens_: MacOSX/Quartz is less of an issue because it ignores most of the hinting
[12:06] <madigens_> i'm not against hinting, i'm just a proponent of "light" hinting in the ttfautohint and adobe cff engine sense :)
[12:06] <sladen> madigens_: it also varies between the weights, different people worked on each
[12:06] <sladen> madigens_: yes, I concur, ttfautohint is the (ultimate) way to go
[12:07] <sladen> madigens_: we will have a zero-day at some point when it is moved to cubic + ttfautohint
[12:07] <sladen> madigens_: the question is when
[12:07] <madigens_> additionally, the regular weight could be made slighly thinner ;)
[12:07] <sladen> madigens_: and how at that point to prove reasonable non-regression with the older cubic->qiuadratic->manually hinted outlines
[12:08] <madigens_> so the typeface is still on the roadmap, good to hear. would be a shame to let it rot
[12:08] <sladen> 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] <madigens_> 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] <madigens_> good luck!
[17:29] <mitya57> Can a package in main have a dependency on package-in-main | package-in-universe?
[17:32] <nacc> mitya57: yes
[17:32] <nacc> (I believe)
[17:32] <nacc> mitya57: because that implies all necessary dependencies are satisfiable with just main
[17:41] <mitya57> nacc, thanks. I think I heard the opposite some time ago, but maybe that has been fixed since then.
[17:49] <nacc> 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] <nacc> mitya57: e.g., i've also seen some with <a> | <b> where <b> doesn't exist in Ubuntu
[17:56] <mitya57> nacc, I have found an example of such a dependency in the same package I am working on (qtbase).
[17:56] <mitya57> So yes, it seems to work ;)
[17:57] <nacc> mitya57: :)
[18:05] <mitya57> tsimonq2, FYI I am building qtbase merge in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2969/+packages
[18:06] <mitya57> Also FYI qtdeclarative will move to universe soon.
[18:51] <tsimonq2> mitya57: ack
[19:34] <jbicha> mitya57: I think the remaining reason qtbase is in main in artful is because ibus-mozc Recommends mozc-utils-gui in the live seed
[20:51] <mitya57> jbicha, interesting
[20:52] <tsimonq2> 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] <mitya57> tsimonq2, of course no, 5.5 → 5.6 transition would break a lot of packages
[20:53] <tsimonq2> mitya57: oh... I forgot Xenial was on 5.5 >_<
[20:53] <tsimonq2> nvm, you're right
[20:53]  * tsimonq2 thought Xenial was on 5.6 and we could Just Update it
[20:57] <jbicha> 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] <mitya57> jbicha, actually it looks like there are more reverse dependencies: https://paste.ubuntu.com/25602299/
[21:04] <tsimonq2> Oh, snapd is a thing
[21:04] <mitya57> Of course getting rid of Qt 5 on ISO is also a good task, as it would save some space.
[21:07] <jbicha> 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] <jbicha> some are already in http://people.canonical.com/~ubuntu-archive/component-mismatches.html at least
[21:10] <mitya57> Oh right.
[21:13] <jbicha> 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] <jbicha> that's how libpoppler-qt5-dev is in main but I don't think it should be…
[21:15] <jbicha> oh, qtubuntu is intentionally in main LP: #1708326
[21:17] <mitya57> Maybe it can be reconsidered if it turns out that it’s the only package keeping Qt in main?
[21:18] <jbicha> I believe because Canonical ships qtubuntu as part of its kiosk products, it needs to be in main
[21:18] <jbicha> is Qt being in main causing you problems?
[21:19] <mitya57> No.
[21:20] <mitya57> The only advantage for me of having it in universe would be that tsimonq2 will be able to upload it :)
[21:20] <jbicha> he could probably apply for ppu for that
[21:21] <mitya57> Right
[21:22]  * mitya57 → bed
[21:35]  * tsimonq2 looks into applying for PPU
[23:48] <fossfreedom> 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:49] <fossfreedom> odd - the 64bit Ubuntu daily is still stuck on the 19th Sept - no builds since then?