=== ro is now known as dax
=== sil2100_ is now known as sil2100
sil2100doko: hello! We would need to get miral included in main: https://bugs.launchpad.net/ubuntu/+source/miral/+bug/165138410:44
ubottuLaunchpad bug 1651384 in miral (Ubuntu) "[MIR] miral" [Critical,New]10:44
dokosil2100: last work day this year, I try to have a look, but otherwise this has to wait til 201710:45
sil2100doko: thanks!10:47
sil2100greyback: ^10:49
=== JanC_ is now known as JanC
caribouIs it possible to get someone from the SRU team to get cloud-init  v0.7.8-49-g9e904bb-0ubuntu1~16.04.3 into xenial-proposed pls ?11:29
xnoxi have just realised that I have just two more work days before I'm done for the year \o/11:58
slashdfor sru, could you please take action on "os-prober" [1.70ubuntu3.2] waiting in the Xenial upload queue (importance : CRITICAL) in order for the pkg to be available in -proposed for testing. This solve a missing dependency in 1.70ubuntu3.1 (currently in -proposed) patch that solve a possible risk of corruption. Again .3.1 is already in proposed, I would like the SRU to go on top and 3.1 should definitely not land in -updates14:48
slashdwithout 3.2 debdiff on top14:48
=== scottt is now known as Guest37114
=== rcj` is now known as rcj
=== rcj is now known as Guest61336
=== Guest61336 is now known as rcj
slangasekstgraber, infinity, kees, mdeslaur: TB meeting now?17:00
mdeslaurslangasek: whoops...sorry...did anyone show up?17:16
GunnarHjbdmurray: Saw you asked about bug #1633678. Yes, indeed I hope that somebody will upload it - that's why ubuntu-sponsors is subscribed. The proposed uploads are in the linked PPA.17:29
ubottubug 1633678 in freshplayerplugin (Ubuntu Yakkety) "Compability issue with adobe-flashplugin" [High,In progress] https://launchpad.net/bugs/163367817:29
bdmurrayGunnarHj: ack, uploading17:41
GunnarHjbdmurray: Great, thanks!17:41
tzerohi guys, new to packaging/maintainership; so far it seems that the packaging process is just a collection of arcane memorization. What's the deal with upstream tarballs? What do maintainers generally do for your normal github project?17:54
nacctzero: have you read the packaging guide (probably the debian one)17:54
tzeronacc: yep, have it up now; wiki.d.o/Packaging/Intro ; it's probably benign, but debuild -us -uc gripes about a lack of upstream tarball17:55
nacctzero: right, so you need an orig.tar.gz (roughly) which corresponds to the upstream you are based off of17:55
rbasaktzero: Github will give you a tarball for any tag.17:55
tzerowhat if the project is just a normal github project? with anything more complex than a hello world application the process seems to fall apart17:56
nacctzero: oftentimes this can be obtained (if the pacakge already exists) with `pull-debian-source`/`pull-lp-source`. Given your question, i assume you need it from upstream directly, which rbasak indicated. From a packaging perspecitve, you could write a debian/watch file and add the github example17:56
naccthen uscan/uupdate will download the upstream tarball as specified17:56
tzerowhat's the common workflow for just iterating on a set of packaging files in-place? since I'm maintaining the application itself, I can change anything needed, but don't want to have to create tags that aren't needed17:57
rbasaktzero: it's useful to keep in mind that Debian will package anything. Release tarballs are a lowest common denominator. There does exist tooling to make things easier for your case, but that does necessarily add complexity.17:57
nacctzero: well, the tags rbasak mentioned are for upstrema releases17:57
nacctzero: which you should already be doing as an upstream :)17:58
nacctzero: not sure i follow what you mean by 'iterating on a set of package files' in place? just do it?17:59
tzerohmm.. so if I create a tag of the current state of things, I can pull a tarball to get around the "18:02
tzero"error: can't build with source format '3.0 (quilt)': no upstream tarball found at"18:02
tzerosorry, IRC client line break issues...18:02
nacctzero: well you tag upstream (totally independent of packaging)18:03
nacctzero: then you can, for instance, setup debian/watch (see `man uscan`) to refer to the github page for downloading upstream tarballs18:03
nacctzero: there is also debmake (amongst many other tools) to start with an upstream tarball (again, this should alrady exist, independent of packaging) and setup some basic debian-ization18:05
tzeroisn't there a chicken-and-egg problem where I'm working on the files under debian/, I'd have to push those to github, download the upstream tarball, and test if it works? I'd just like to test the package building locally, before pushing the debian/ directory to github and revealing my ignorance to the world :)18:05
nacctzero: debian/ is *not* in the upstream tarball normally18:06
nacctzero: i think you're making it way more complicated :)18:06
nacctzero: upstream tarballs are 'pristine' in some sense -- unaltered upstream sources18:07
nacctzero: you may want to read `man dpkg-source`18:07
nacctzero: specifically (in your case) the "Format: 3.0 (quilt)" section to understand how the package gets built18:08
tzerohmm, so unlike RPM, the intermediary source package is required in this case18:08
nacctzero: what do you mean by "intermediary source package"? There is an 'orig' tarball, which is not a package, and then a source package (which is what you're building now) and that builds (possibly many) binary packages18:09
tzeroI'm just trying to get a generic concept of what's going on.. in RPM-land, the spec builds either the source package (.src.rpm) or the "desired end result" (.rpm); in arch and gentoo land, it's much more straightforward. but with dpkg/deb/dsc, it seems like the "spec" file builds a dsc, which then is used to create the desired end result (.deb)18:12
naccyes it's different in .deb18:12
naccthere is no 'spec' for one thing :)18:13
nacca source package is a '.dsc' file basically18:13
naccas the .dsc file includes hashes of the tarballs used18:14
naccand the binary packages that get built from it18:14
naccyou then build a source package into binary packages18:14
tzeroah ha... gotcha, thanks18:15
tzeroI appreciate the patience and hand-holding; I'll read through some more stuff and see how it goes; thanks again18:18
nacctzero: just keep asking questions :)18:19
tzeroI stumbled on pdebuild at some point, it build some .deb files, but those didn't contain any of the application files at all. Is that a wrapper utility over the standard debuild? I found little mention of the .install file, but that seems necessary18:22
nacctzero: i don't think you want to use pdebuild/pbuilder18:23
nacctzero: i would suggest using sbuild at this point18:23
nacctzero: or dpkg-buildpackage itself, if you want18:23
tzeroand dpkg-buildpackage being the lowest-level of those utilities?18:31
nacctzero: yes, aiui18:37
infinitytzero: FWIW, in your above example, spec files and debian/rules are pretty much 100% analogous.  Yes, the way Debian developers prefer to work is to build a .dsc and then feed the .dsc to sbuild to produce debs, but that's no different than building an .srpm and feeding that to a build script to build an .rpm.  It's just that people in RPM land tend to be more reckless. ;)19:11
infinitytzero: The "reckless" option in deb land is there too, just "dpkg-buildpackage -b" and boom, you have .deb binaries, no need to build the source package first (or just dpkg-buildpackage with no options will build source and binary in one go).19:12
tzeroinfinity: whoa, dpkg-buildpackage -b is great19:27
=== slashd- is now known as slashd
tzerois there a better way to determine where files should be placed into the filesystem other than override_dh_install? by default, a package.install file containing lines such as 'usr/lib/python*/foo.py' only get included if I prefix the path to 'debian/package'19:50
tzeroand even then, lintian says the files would actually be installed into '/debian/package/usr/lib/...'19:50
tzerowithout the .install file, the package only contains the default text files like COPYRIGHT, etc. If it makes a difference, the project has both GTK and Qt frontends, which are distributed as separate packages19:53
rbasaktzero: you're packaging a Python thing? We have helpers for Python, so if you have a setup.py that works, the packaging effort becomes minimal. See dh_python3(1).20:00
dobeytzero: generally, you shouldn't need to override_dh_install; by default just having usr/blah/foo in the .install files in multiple-binary-package scenarios should work. only if the files aren't installed via normal build system install rule, would there normally be a problem there20:04
dobeyyou shouldn't build with the prefix set to /debian/package20:05
dobeythe defaults should be sufficient20:05
tzerooh, less is more I guess, whatever blog I initially read said to define a bunch of things20:15
infinitytzero: Less is definitely more in the new dh(1) style rules files.  An ideal package should require zero overrides, and that's the best position to start from.20:20
infinitytzero: If something is particularly troublesome, but you feel like it's a something that dozens of other people should surely have suffered (like python modules), you'll often find there's a "dh --with foo" module that does all the heavy lifting.20:21
infinitytzero: And the added advantage of modules like dh-python, dh-systemd, etc is that they also make sure that, even if your upstream is vaguely Fedora or Arch centric, or just plain old /usr/local FHS, you'll often get magically mangled into something that plays nicely with Debian policy and other packages on the system.20:22
tzerooh, neat20:23
tzerois this a relatively new development in debhelper/cdbs?20:23
infinityDepends on how one defines "new".20:24
infinitydh(1) came to being in debhelper 7.  Which was in 2008.  But for some of us, that's indeed new. :)20:25
infinityThe subsequent years have involved educating people to stop using cdbs and old-style debhelper rules.20:25
infinityAnd people writing clever addon modules to keep debian/rules tiny in the face of complex problems.20:26
naccso i think the reason that php-horde-crypt is current stuck in excuses (and failing it's own autopkgtest) is that gpg by default doesn't have any secrets stored. THe debian autopkgtest 'pass' because in their env there is no /usr/bin/gpg and therefore all tests are skipped :/20:28
naccany ideas on how to fix that up? or is there a well-established 'set up gpg secrets for testing' example?20:28
infinitynacc: One could argue that the testbed shouldn't have gpg installed, but unlike builds, where we want minimal pollution to build reproducibly, it's almost better to have slightly dirty systems for running tests.20:29
infinitynacc: But, that debate aside, if the tests attempt to test a thing when gpg is there, I'd say that (a) gpg is an undeclared test dep, and (b) it should be made to pass said tests.20:30
naccinfinity: agreed, i can work on (b), although i think primarily it's just lacking a 'configure a fake gpg secret' (based upon some cursory debugging so far that gpg basically complains about there being no secrets)20:31
naccinfinity: but yeah, it probably should be an explicit dep and the tests should be fixed, you're right20:32
infinitynacc: As for well-established snakeoil.  I dunno.  Probably not.  But I'd suggest pregenrating an ascii-armored keypair and shipping it with the tests.  Generating keys at runtime is problematic (see, for instance, the kernel hack that starts generating a key at the beginning of the build and hopes enough entropy has been generated by the end that one showed up in the background).20:32
infinityAnd, yes, the kernel has lost that race before. :P20:32
naccinfinity: good idea on the keypair20:32
infinityThough I think the current iteration of upstream makefiles are more resilient to that, and wait correctly.20:32
=== NComman`` is now known as NCommander
=== NCommander is now known as Guest25482
=== JanC is now known as Guest67153
=== JanC_ is now known as JanC
vertago1I am trying to get a package development environment setup for the avahi package but when I check it out with bzr the debian folder is missing. Is there a step I am missing?22:31
naccvertago1: is avahi actually maintained in bzr?22:31
vertago1possibly not22:31
vertago1It is on launchpad22:31
naccvertago1: it's not in bzr22:32
vertago1ok, so I should use debian's tools?22:32
naccvertago1: i'd recommend using `pull-lp-source`22:32
vertago1I am getting an error with that command so I think I will just forego using bzr with what I am working on then22:35
vertago1I was trying to figure out the least-headache-way of creating a patch in an existing source package to fix an upstream bug.22:36
naccvertago1: my quick and dirty method:22:39
naccvertago1: pull-lp-source <srcpkg name>22:39
naccvertago1: cd <srcpkg name-version>22:39
naccvertago1: git init . [note this can issues if the upstream also uses git and they provide any .git* files in the tarball]22:40
naccvertago1: git add .22:40
naccvertago1: git commit -m <msg>22:40
naccvertago1: do some changes and either commit them as a quilt patch if it's to the source22:41
sarnoldman I have trouble believing -git- is in the quick-and-dirty variant :)22:41
naccvertago1: add a changelog entry22:41
vertago1I know git fairly well so it should work for me.22:41
naccsarnold: it's mostly so `git diff` tells you what you broke^Wchanged22:41
naccvertago1: so you're backporting an upstream fix?22:42
vertago1no I am writing a fix to hopefully push upstream22:42
naccvertago1: oh, why do you need the ubuntu package at all then?22:42
vertago1it makes testing it easier22:42
naccvertago1: for testing?22:42
vertago1one of the packages is avahi-daemon22:42
vertago1so if I can install the package I don't have to mess with the daemon config.22:43
vertago1I just need to add some checks so that avahi-daemon doesn't send invalid utf8 strings over dbus22:43
naccvertago1: understood22:43
vertago1*try to send22:43
nacccpaelzer: i think you need an AA to help usher strongswan through, btw23:22
nacccpaelzer: it's in the new queue due to new binaries23:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!