[00:00] <kuldeep> i want to keep `libbox0.so.2 libbox0-2 #MINVER#` like libpipeline1.
[00:01] <kuldeep> do i have to keep like `libbox0.so.2.0.0 libbox0-2 #MINVER#` and update everytime the SO VERSION?
[00:03] <nacc> kuldeep: does your binary package create a libbox0.so.2?
[00:04] <nacc> kuldeep: becuase libpipeline1 contains both:
[00:04] <nacc> /usr/lib/x86_64-linux-gnu/libpipeline.so.1
[00:04] <nacc> /usr/lib/x86_64-linux-gnu/libpipeline.so.1.4.1
[00:04] <nacc> which one a symlink to the other
[00:05] <kuldeep> afaik: file libbox0.so.2.0.0  and symbolic link libbox0.so -> libbox0.so.2.0.0
[00:05] <nacc> libbox0.so is wrong, isn't it?
[00:05] <nacc> an unversioned lib?
[00:06] <kuldeep> nacc, https://paste.debian.net/903842/
[00:06] <kuldeep> libbox0.so is a symbolic link to libbox0.so.2.0.0.  is that a problem?
[00:06] <nacc> kuldeep: right so your symbols file and the contents of the package disagree
[00:06] <nacc> kuldeep: you told the symbols file to look at a library called libbox0.so.2
[00:06] <nacc> but you don't ship any such library
[00:07] <nacc> so the build system recognizes that and switches to the library it did find
[00:07] <nacc> afaict that's what the log you got is saying
[00:07] <kuldeep> nacc, will it be happy (with the symbolic link?) "`libbox0.so libbox0-2 #MINVER#`"  ?
[00:08] <kuldeep> [checking my trick]
[00:08] <cjwatson> libbox0.so belongs exclusively in libbox0-dev
[00:09] <cjwatson> libbox0-2 should ship libbox0.so.2 as a symlink to libbox0.so.2.0.0
[00:09] <nacc> kuldeep: I don't know, maybe? but you have to refer to an actually shipped library either way; that seems like it should work, but it seems odd that you're not shipping libbox0.so.2
[00:09] <cjwatson> you must ship the thing that's named in your SONAME or stuff won't work
[00:09] <nacc> kuldeep: so then, no, you should't do your trick, as it's not in the same package
[00:09] <kuldeep> ok
[00:10] <cjwatson> it is not correct to use libbox0.so in .symbols - that field is supposed to be the SONAME
[00:10] <kuldeep> cmake isnt generating the libbox0.so.2 and libbox0.2.0 have to look into that.
[00:10] <cjwatson> right, fix that.
[00:11] <nacc> cjwatson: right, duh, thanks for clearing that up :)
[00:11] <cjwatson> and re symbols containing 0.3.0+65, you're meant to edit that.
[00:12] <cjwatson> it'll only automatically fill in the minimum version if the symbols file didn't already have a version for that symbol.
[00:12] <nacc> kuldeep: right i think cjwatson's advice earlier was to use makeshlibs to give you a base symbols file that you then make correct in practice
[00:12] <cjwatson> it just uses the current version because that's the conservative choice and it can't know any better.
[00:13] <nacc> i think dh_makeshlibs even mentions that :)
[00:22] <tsimonq2> So do Bad Things happen when I accidentally close a terminal when it's dputting to a PPA and it's on the source tarball?
[00:23] <kuldeep> cmake only allow me to set "SET_TARGET_PROPERTIES(box0 PROPERTIES SOVERSION <so-value-here>")   but it only allow one value.
[00:23] <kuldeep> multiple call to SET_TARGET_PROPERTIES result in final only being generated.
[00:24] <kuldeep> so, either i can generated libbox0.so.2 or libbox0.so.2.0 or libbox<IP_ADDRESS>     +    a symbolic link libbox0.so to the actual shared library
[00:28] <kuldeep>  /usr/lib64/libpipeline.so -> libpipeline.so.1.4.1  |  /usr/lib64/libpipeline.so.1 -> libpipeline.so.1.4.1   |  /usr/lib64/libpipeline.so.1.4.1
[00:32] <nacc> kuldeep: keep in mind that libpipeline.so  lives ina  different binary pacakge
[00:41] <kuldeep> nacc, it is mandatory to provide /usr/lib64/libpipeline.so -> libpipeline.so.1.4.1 ?
[00:49] <nacc> kuldeep: well, in the -dev package, probably? otherwise how would you compile against it?
[00:49] <nacc> *link* against it, rather
[01:05] <cjwatson> tsimonq2: no; either it finished anyway or the whole thing is discarded
[01:05] <cjwatson> kuldeep: /usr/lib64/ isn't a thing in Ubuntu
[01:05] <tsimonq2> cjwatson: Thanks.
[01:05] <cjwatson> kuldeep: but yes, a libfoo.so symlink is required in the -dev package as nacc says, since that's what ld looks for
[01:06] <kuldeep> cjwatson, ok
[01:06] <cjwatson> I can't believe that cmake is actually as useless as you're suggesting though; I'd suggest you find a competent existing library package that's built using cmake
[01:07] <kuldeep> cjwatson, atleast it isnt doing the that by default.
[01:08] <kuldeep> finding libraries that uses cmake is hard. trying ...
[01:08] <kuldeep> im doing on https://anonscm.debian.org/cgit/users/
[01:10] <cjwatson> grep-dctrl -FBuild-Depends,Build-Depends-Indep cmake -a -Pr ^lib -nsPackage /var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_*_Sources | sort -u
[01:10] <cjwatson> (well, maybe not gb.archive in your case)
[01:10] <cjwatson> should find you a decent list to poke at
[01:11] <tsimonq2> cjwatson: Speaking of that, is there a technical reason why we don't have an httpredir.debian.org for Ubuntu?
[01:12] <cjwatson> not afaik
[01:13] <tsimonq2> Then who do I talk to about asking that Canonical set one up? :)
[01:15] <cjwatson> RT, I'd presume ...
[01:16] <tsimonq2> cjwatson: Oh, so do you think it would be worth bringing up for discussion or should I Just File The Goshdarn RT? :)
[01:16] <cjwatson> I have absolutely no idea
[01:16] <tsimonq2> Ok, fair enough \o/
[01:16] <cjwatson> it's nearly end of year and I'm just trying to finish off my project so I can stop :P
[01:17] <tsimonq2> cjwatson: Fair enough, cheers, good luck, happy holidays. :)
[01:17]  * tsimonq2 takes note to not poke Colin until January so he can finish his project
[01:24] <kuldeep> https://anonscm.debian.org/cgit/users/abe/nmu/plplot.git/tree/debian  PLplot dont have any symbol file.  (uses cmake)
[01:38] <kuldeep> cjwatson, https://cmake.org/cmake/help/v3.0/command/install.html    it says "lib<name>.so -> lib<name>.so.1"    documented as im seeing
[01:38] <cjwatson> I think you'd be best off not addressing me about cmake issues
[01:38] <cjwatson> I don't personally like it and don't use it, so can't help you further there
[01:39] <kuldeep> cjwatson, i pinged you because of "I can't believe that cmake is actually as useless as you're suggesting though; I'd suggest you find a competent existing library package that's built using cmake"
[01:39] <kuldeep> so, atleast i found in the documentation :)
[01:39] <cjwatson> but if you mean what the symlink target should be, then it doesn't matter whether it's to lib<name>.so.1 or to lib<name>.so.1.X.Y
[01:39] <cjwatson> it just has to exist at all
[01:40] <cjwatson> anyway, please stop pinging me about cmake-related things, thanks :)
[01:40]  * tsimonq2 coughs at #debian-mentors on OFTC and #ubuntu-motu on freenode as well...
[01:40] <cjwatson> yep, much better venues for all this
[01:40] <cjwatson> basically none of this is specific to launchpad.net at this point
[01:40] <kuldeep> cjwatson, ok. (maybe i should stop giving you reason to curse cmake :p )
[01:42] <tsimonq2> Oh jeez, looks like someone's doing a mass rebuild... :P
[01:42] <kuldeep> cjwatson, nacc and dobey for helping me out throughout the way of learning, building my first debian package. i have been a constant source of ping's for you :D
[01:44] <kuldeep> cjwatson, nacc and dobey THANK YOU for helping me out
[01:44] <tsimonq2> kuldeep: Although I haven't helped much, don't give up here! Go get help in those channels I listed. I'm not an expert but you just have to keep at it and you'll become good. ;)
[01:45] <tsimonq2> (I'm not good but I'm better than I was 3 months ago...)
[01:45] <kuldeep> :)
[01:47] <kuldeep> for the past two days, i have been slicing cjwatson libpipeline package and result in a ping when share any link. im have saturated cjwatson. sorry :)
[01:49] <kuldeep> thanks you to tsimonq2 and wgrant (and anyone i missed) too.
[01:51] <nacc> kuldeep: np, gl!
[02:03] <kuldeep> :)
[10:57] <kuldeep> Finally, i got my deb file without error. :D
[10:57] <kuldeep> (my fault not cmake because i didnt set the SOVERSION and VERSION properties correctly)
[10:57] <kuldeep> so, finally i got the libbox0_0.3.0.tar.xz  libbox0-2_0.3.0_amd64.deb  libbox0-dev_0.3.0_amd64.deb   /var/cache/pbuilder/build/
[15:35] <jabowery> In July a maxima package bug was fixed that still hasn't shown up in the xenial updates.  No one is assigned.  What is a reasonable course of action?
[15:36] <dobey> #ubuntu-devel is where you want to ask about ubuntu development
[15:38] <jabowery> The reason I asked here is this response to the launchpad bug tracking:  "A thing the maintainer perhaps could do would be to create a launchpad mirror of the sourceforge repo maxima's code is kept in - and then to initiate a nightly build ppa for maxima." https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/1602941/comments/8
[15:38] <ubot5`> Ubuntu bug 1602941 in maxima (Ubuntu Xenial) "Draw cannot be loaded in 16.04 (Repackage needed since gcl has changed?)" [Undecided,Confirmed]
[15:47] <dobey> yes, but that doesn't get it into xenial updates
[15:47] <dobey> if someone wants to create a daily build PPA, they can. but it doesn't have anything to do with fixing bugs in ubuntu itself
[15:51] <cjwatson> yeah, that comment is from somebody uninformed but trying to be helpful, rather than somebody who knows about how stable updates happen


[00:25] <berglh> can anyone tell me how to update the ulimit for nofiles (soft/hard) for a non-root user on ubuntu 17.10 without restarting the whole server? when i edit /etc/security/limist.conf and /etc/systemd/user|system.conf and set the nofiles limits, then logout of the box and back on, the new settings for the user don't take effect. am i missing something?
[03:32] <chamar> join #go-nuts
[07:15] <lordievader> Good morning
[11:38] <jancoow> Hi. I'm running a ubuntu server for several years now. I've a feeling that the performance of my fileserver is going down. I've like ~10 harddisk inside it and I'm using greyhole. I wanna know from each disk if they have some problems etc.
[11:38] <jancoow> how can I do this the best
[11:38] <jancoow> I don't get all the SMART information and I've no clue if the tests are up-to-data
[11:38] <hateball> jancoow: if they support S.M.A.R.T, query with smartctl
[11:38] <jancoow> yeah all of them have smart
[11:41] <jancoow> hateball: could you maybe help me a bit further? :)
[11:41] <jancoow> I just wanna make sure everything is all right :)
[11:42] <jancoow> Maybe my samba configuration is just wrong;
[11:44] <hateball> jancoow: pastebin your smartctl output and I can have a look
[11:51] <jancoow> hateball: do you want individuel pastebins for each drive?
[11:54] <jancoow> hateball: hdd1: https://jancokock.me/f/49c53 hdd2: https://jancokock.me/f/1377e hdd3: https://jancokock.me/f/de675 hdd4: https://jancokock.me/f/9b81b hdd5: https://jancokock.me/f/70c46 hdd6:  https://jancokock.me/f/e4ef3 hdd7: https://jancokock.me/f/8a5e5
[11:57] <rbasak> jancoow: if ext4 then "e4defrag -c ..." is useful
[11:57] <jancoow> rbasak: defrag for ext4  ? :O
[11:57] <rbasak> It'll tell you if it's required.
[11:57] <rbasak> Hopefully not :)
[11:58] <jancoow> i'm also running badblocks now
[11:58] <rbasak> But pathological cases will be able to fragment any filesystem I think.
[11:58] <rbasak> And it's easy and quick enough so you might as well eliminate that.
[12:01] <jancoow> how long does it take for the command to finish?
[12:02] <hateball> jancoow: look at the error rates on hdd2
[12:03] <hateball> .. and hdd3
[12:03] <hateball> 4 and 5 also has some, tho not nearly as bad
[12:04] <jancoow> what are these rates?
[12:04] <jancoow> again these stupid seagates..
[12:04] <jancoow> 2 years ago they both failed at the same time
[12:05] <jancoow> lost a lot of data (which was redunant stored on both..)
[12:05] <jancoow> I did got 2 new ones because I was still under RMA
[12:05] <jancoow> but now they are failing again??
[12:07] <hateball> well it can be the controller as well
[12:07] <jancoow> rbasak: http://jancokock.me/f/6045f/ still wating on hdd3
[12:07] <jancoow> hateball: should I run badblocks on them?
[12:08] <jancoow> so I can check if there are any bad blocks?
[12:08] <jancoow> I think I will move the landing disk from greyhole to hdd1. I don't trust these seagates anymore
[12:09] <hateball> oh I didnt even notice they were seagate and not WD. seagate report smart data differently
[12:09] <jancoow> Yeah that's one thing I hate about smart. There is no actual standard
[12:09] <jancoow> And the raw values are sometimes encoded..
[12:09] <jancoow> Why just not one standard which makes it easy for everyone
[12:11] <hateball> Because https://xkcd.com/927/
[12:11] <jancoow> yeah exactly
[12:12] <rbasak> jancoow: I think you actually need to ready the output of -c.
[12:12] <rbasak> -c tells you whether it's needed. It doens't actually do it.
[12:13] <jancoow> It says "Done."
[12:13] <jancoow> I will try without running the command in the background
[12:13] <rbasak> standard> SMART is a standard. The individual parameters checked can be manufacturer-specific. But if the disk thinks there's something wrong, smartctl will tell you that.
[12:13] <rbasak> Yeah it should give you more output than that.
[12:13] <rbasak> (IIRC)
[12:14] <jancoow> yeah I know, smart is the standard
[12:14] <jancoow> but indeed the values are specific
[12:14] <jancoow> and that's what I hate
[12:16] <jancoow> rbasak: https://jancokock.me/f/33e32
[12:20] <rbasak> The "I think I'm about to fail" indication isn't specific though.
[12:21] <rbasak> jancoow: sorry. The manpage says to use -v as well.
[12:21] <jancoow> oh I needed root permissions
[12:52] <jancoow> rbask
[12:52] <jancoow> rbasak: after I used the sudo command I do get some more information
[12:52] <jancoow> It has 5 fragmented files
[12:53] <jancoow> so that's not a big issue
[12:54] <rbasak> Great!
[12:54] <jancoow> rbasak: now checking the other 6 disks ;p
[13:10] <jancoow> rbasak: yay. None of them need defrag
[13:18] <theGoat> so i have some nfs exports on my ubuntu 14.04 server, but the transfer rates seem slow.  only able to write at about 50 MB/s or so.  SCP i am able to push close to 90.   is there any tuning i can don on the nfs server?
[14:35] <andreas> theGoat: try rsize and wsize
[14:53] <theGoat> andreas: yeah i have them set to 65536
[15:03] <joelio> theGoat: udp mode any quicker?
[15:03] <theGoat> let me give it a whack
[15:03] <joelio> should be udp default iirc
[15:04] <joelio> if it is udp, you might want to wrangle your rmem kernel params etc
[15:05] <theGoat> joelio: udp doesn't seem to be any better.  kernel params on the client or server side
[15:06] <joelio> perhaps check the rmem settings then, only other thing I can suggest
[15:06] <theGoat> joelio: on the server or client side?
[15:06] <joelio> both really, check out http://www.tldp.org/HOWTO/NFS-HOWTO/performance.html or something similar
[15:07] <joelio> (may be a bit old that, but still is valid) - also vhat version of NFS, 3 or 4?
[15:17] <theGoat> figured it out.  had the export set to sync, and not async.  once i changed it to async:
[15:17] <theGoat> dd if=/dev/zero of=/nfs/software/zerofile bs=1024k count=500
[15:17] <theGoat> 500+0 records in
[15:17] <theGoat> 500+0 records out
[15:17] <theGoat> 524288000 bytes transferred in 7.002229 secs (74874441 bytes/sec)
[15:32] <joelio> cool, got there in the end
[15:42] <theGoat> yep
[15:42] <theGoat> thanks for the help
[16:03] <joelio> np dude
[18:04] <albech1> anyone know of an interface for administrating websites on a shared webserver. the different departments in our company need this for wikis etc.
[18:42] <andreas> nacc: what's the preferred way to use the git workflow to update the version of a package? That doesn't come from debian. It's a plain new upstream version
[18:43] <nacc> andreas: uupdate/uscan, probably
[18:43] <nacc> andreas: i can tell you how I have done it, if you want. HO?
[18:43] <andreas> and then git commit/delete as necessary?
[18:43] <andreas> add/delete I meant
[18:43] <nacc> andreas: right, uupdate will create a new directory
[18:43] <andreas> yes
[18:43] <nacc> andreas: you'll need to effecitvely move it in place over your git repo
[18:43] <andreas> ok
[18:44] <nacc> andreas: it's something i want to wrap better, as that can be error prone :)
[18:44] <andreas> I was just wondering if there was such a wrapper already :)
[18:44] <andreas> thx
[18:46] <nacc> andreas: `git status --ignored` can help, to see what has updated
[20:43] <blizzow> Does anyone here know if the nagios-nrpe-server package is fixed to honor the allow arguments flag in the config? Last I checked it was broken and wouldn't read the allow arguments flag.
[20:45] <nacc> blizzow: is there a bug?
[20:49] <blizzow> nacc, there have been some firefights with the maintainer saying that the args option a security hole. The point of the feature is to let the user choose. Having the option is not a security hole, setting the option is.
[20:51] <blizzow> It's like disabling the ability to set the listening address in mysql via the conf file.  Yes, if you set it to <IP_ADDRESS>, you could be in for a bad time. But the designers intended the behavior to be configurable. Intentionally breaking the ability to configure certain parts is asinine.
[20:52] <nacc> blizzow: i meant is there a bug #, not your opinion on the bug :)
[20:52] <blizzow> nacc: there have been multiple bugs filed, the maintainer consistently closes them citing "security hole"
[20:52] <blizzow> like a TSA agent.
[20:53] <nacc> blizzow: ... give me the bug numbers?
[20:53] <nacc> blizzow: and more importantly, is there an ubuntu bug filed?
[20:54] <blizzow> https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258
[20:55] <nacc> blizzow: well, that's fix released in all ubuntu releases.
[20:55] <nacc> blizzow: so not sure what you were just talking about?
[20:57] <blizzow> It's not clear to me which way the package maintainers have decided to swing, allow command args to be configured, or disable them entirely.
[20:58] <blizzow> I was hoping to get an answer here before installing, testing, and possibly rebuilding.
[20:58] <nacc> blizzow: it is fixed in Ubuntu.
[20:58] <nacc> blizzow: as that bug says, a few times.
[20:59] <nacc> blizzow: you will need to modify your configuration to allow it locally.
[20:59] <nacc> blizzow: the functionality is there by default, but disabled.
[21:00] <blizzow> I guess I'll try the latest.
[21:00] <nacc> blizzow: latest what?
[21:00] <nacc> blizzow: you don't to run Artful to get the fix.
[21:01] <nacc> *don't need to run
[21:01] <blizzow> package. like I said, the maintainer for a long time was marking the bug "fixed" because args are a security hole if not used properly.
[21:02] <nacc> blizzow: well, yes, you'd try the latest package. Not sure what else you'd try? Sorry, this feels like a rather circular converstaion.
[21:02] <nacc> blizzow: also, I think you mean the Debian maintainer? As the LP bug says, Ubuntu has decided to diverge from Debian on this issue.
[21:03] <sarnold> have you tried since may?
[21:05] <blizzow> I was just hoping to get an answer here before testing the current package, that's all. I spent a bunch of time building a system to build a custom deb with it enabled to distribute among my systems.
[21:05] <nacc> blizzow: why wouldn't you use a PPA ?
[21:06] <nacc> blizzow: but regardless, yes, fixed.
[22:17] <rh10> guys, which version of python do you mostly use for system administration tasks? or devops?
[22:17] <rh10> 2 or 3?
[22:17] <teward> nacc: rbasak: dpb1: et. al.: I may have a meeting conflict tomorrow with a client, so I might not be able to chair the meeting this week.  Sucks that clients are slow at responding to me.
[22:19] <dpb1> teward: hah
[22:19] <rh10> and how long python 2 will b esupported? is next LTS ubuntu version will be shipped with python 2 onboard?
[22:19]  * dpb1 looks at schedule
[22:19] <teward> dpb1: i'mma pull myself off the chair list, bother me later :P
[22:19] <teward> rh10: I use Py3 because Py2 dies in 2020
[22:19] <teward> and Py3 is becoming the standard
[22:19] <dpb1> teward: ok, sounds good
[22:19] <rh10> teward, thanks
[22:19] <teward> rh10: i think both will be in the repositories, but Py2 is *dead* in 2020 by upstream
[22:20] <dpb1> teward: let us know when/if your schedule is more "predictable". :)
[22:20] <teward> dpb1: who should I put in for it, rbasak, you, or TBD?
[22:20] <teward> dpb1: will do.
[22:20] <dpb1> teward: who is next up?
[22:20] <teward> rbasak
[22:20] <teward> after me
[22:20] <dpb1> put him in for next, he can slide the next person up if he wants (his schedule is a bit weird now too).
[22:22] <teward> done
[23:12] <drab> hi, anybody around using netdata, possibly with influxdb as a backend storage?
[23:14] <sarnold> "auto-detects everything, it can collect up to 5000 metrics per server out of the box" mmm nice for the very lazy admin like me :)
[23:14] <drab> the other interesting thing is that it's very much lxc aware
[23:14] <drab> so it plays really nicely with all the containers I have
[23:16] <sarnold> some of these screen capture/video/image things are really cool
[23:16] <drab> I've had this sort of problem forever, being able to look at what's happening "right now" in high def and have historical
[23:17] <drab> that's how I used to use collecd
[23:17] <sarnold> everyone has :) e.g. pcp is ~twenty years old now..
[23:17] <drab> but the frontend stuff is non-existing/a pain for high res
[23:17] <drab> so netdata + influx may finally be a way to fix this
[23:18] <drab> especially since the data at that high rate doesn't need to leave the box, which is the other issue if you even say you're sending stuff to statsd somewhere closeby, still lots of stuff leaving the host
[23:21] <sarnold> zfs support :)
[23:23] <drab> yep, only cavia is that being zfs at kernel level and therefore all containers sharing the same kernels those numbers are repeated
[23:23] <drab> I'm still trying to figure out exactlty what to do with that part
[23:23] <drab> maybe there's something I'm misunderstanding


[05:28] <skaet> JackYu, slangasek - when all the teams have got the images marked ready who want to release,  we'll be releasing.
[05:34] <skaet> since Laney will be driving the bits,  we'll be trying to get it all ready during the UK working day timezone.
[05:35] <skaet> xnox - links to each of the flavors announce and images can be found: https://wiki.ubuntu.com/SaucySalamander/Beta1
[05:39] <skaet> Laney,  can you double check that the links for the downloads in ^ are matching the locations we'll be publishing to.
[05:39] <skaet> ?
[05:41] <skaet> Laney, and on that note,  if it hasn't been done already,  can you pre-publish the CD images?
[05:42] <skaet> when you come on line.
[05:42] <skaet> :-)
[05:43]  * skaet --> zzz,   see you on the flip side.
[08:36] <xnox> skaet: i have not idea what to do with those links to flavour release notes.
[08:36] <xnox> s/not/no/
[08:37] <cjwatson> xnox: the web team has a redirection table that can be per-flavour
[08:38] <xnox> cjwatson: would it help for lubuntu cd to have .disk/release_notes_url ?
[08:42] <cjwatson> It sure would
[08:44] <cjwatson> xnox: done, also for Mythbuntu and Ubuntu GNOME
[08:44] <cjwatson> (for the next build, of course)
[08:44] <xnox> thanks...... I wonder if they would want to respin =/
[08:44] <cjwatson> Seems a pretty minor point to respin for
[08:54] <xnox> cjwatson: what os= names did you give them? mythbuntu ubuntugnome lubuntu
[08:56] <xnox> cjwatson: kylin also missing release_notes_url.
[08:56] <xnox> are the urls set on the nusakan?
[08:57] <cjwatson> xnox: mythbuntu lubuntu ubuntu-gnome (as standard in cdimage)
[08:57] <cjwatson> yes they are
[08:57] <cjwatson> ah yes, ubuntukylin too ...
[08:58]  * cjwatson applies that one as well
[08:59] <cjwatson> lp:~ubuntu-cdimage/debian-cd/ubuntu tools/add_live_filesystem FWIW
[09:33] <xnox> cjwatson: #web-team has setup the redirects, but the os= field seems to get truncated at 10 characters limit, thus e.g. ubuntustudio, ubuntu-gnome, ubuntukylin are too long, get chopped and fail to redirect.
[09:34] <cjwatson> xnox: I very much doubt that's the fault of our end :)
[09:34] <xnox> cjwatson: should #webteam work on apache redirects to make those work, or can we reasonably change to shorter names, e.g. studio, gnome, kylin?
[09:34] <cjwatson> they should fix that
[09:34] <xnox> cjwatson: ok.
[09:34] <cjwatson> I don't want to make things irregular at our end - it will just be confusing later
[09:34] <cjwatson> I have real trouble believing that their software stack cannot be fixed
[09:35] <cjwatson> (and not by apache redirects, but by just handling longer values of os= directly)
[09:47] <xnox> cjwatson: yeap, Peter agreed but asked for an RT ticket, which I am filing.
[09:47] <cjwatson> ok
[10:17] <Laney> highvoltage: how you looking for b1?
[10:17] <Laney> Think I'm going to lift the block
[10:59] <smartboyhw> Laney, what is missing now for the release of Beta 1 to be official?
[11:00] <Laney> readiness of the remaining flavours, skaet to be around to send the announcement[D[D[Ds
[11:00] <Laney> with less mangling
[11:00] <smartboyhw> Laney, OK
[11:03] <Laney> I'm rusty on how to drive the release scripts so it might take a short while
[11:28] <highvoltage> Laney: we had an ltsp live problem but it doesn't have to block anything
[11:28] <Laney> yeah, saw that one
[11:38] <Laney> OK, unblocking
[11:39] <Laney> highvoltage: don't forget to mark as ready if you are happy enough
[12:08]  * cjwatson moves ruby-augeas to main since it's just a rename of libaugeas-ruby
[12:15] <sil2100> Hi! I would need anyone from the release team to take a look at the https://bugs.launchpad.net/ubuntu/+source/autopilot/+bug/1220494 FFe - it's important for our daily-release process, as it's impacting us heavily
[12:15] <ubot2`> Launchpad bug 1220494 in autopilot (Ubuntu) "[FFe] Add check so we can determine if the Mouse is caught in an endless loop." [Undecided,Confirmed]
[12:17] <cjwatson> sil2100: approved
[12:18] <highvoltage> stgraber: I went ahead and marked them as ready ^^^ - will just have to note the ltsp-live breakage
[12:19] <sil2100> cjwatson: thank you!
[12:21] <darkxst> Laney, Hi, sorry I was away bike fixing
[12:21] <darkxst> we are good to go, images are ready so you can remove the migration blocks!
[12:26] <smartboyhw> \o/
[12:26] <smartboyhw> darkxst, it has been removed before you said it:P
[12:28] <darkxst> smartboyhw, ok
[12:51] <NikTh> Hello,
[12:51] <amjjawad> NikTh: hi :)
[12:51] <amjjawad> good to see you here
[12:51] <NikTh> I know that most of people don't use these sites, but have a look here please
[12:51] <NikTh> http://old-releases.ubuntu.com/releases/12.04.0/
[12:52]  * smartboyhw wonders who uses 12.04.0 -.-
[12:52] <amjjawad> Laney: are you there? it appears that I have no access to set a build to ready: http://iso.qa.ubuntu.com/qatracker/milestones/302/builds
[12:52] <NikTh> It has 12.04.2 instead of 12.04.0 .. I know that 12.04.0 is in the DIR (if you scroll down..) but maybe it would more ... correct ... if it had 12.04.0 at the top
[12:53] <amjjawad> darkxst: already have done that but for the next time, I guess I can do it but I have no admin panel
[12:55] <skaet> Riddell,  ScottK - you ok with the updgrade testing on Kubuntu?   or still finishing off some tests?
[12:56] <skaet> amjjawad,  what are you wanting to change on the admin panel
[12:56] <skaet> ?
[12:56] <amjjawad> skaet: hi
[12:56] <smartboyhw> skaet, I think he wants to mark the images ready
[12:56] <Riddell> skaet: yeah that's fine
[12:56] <amjjawad> skaet: Laney has asked to mark the build as Ready for Beta 1 but I don't have access
[12:56] <Riddell> skaet: the Upgrade (image) test for kubuntu should be scrapped but I always get lost in that tracker for some reason so not been brave enough to do it
[12:57] <amjjawad> skaet: it is done already by Tim but for the next time, I'd like to do it myself
[12:57] <NikTh> amjjawad: -) hi , we had some unexpected news lately .. a ? (Team Leader.. etc)
[12:57] <smartboyhw> Riddell, image-based upgrades failed for us:P
[12:57]  * smartboyhw hates that *unexpected* news
[12:58] <skaet> amjjawad,  makes sense.
[12:59] <skaet> smartboyhw,  bug number for the release notes?   Anything specific you want to write up?
[12:59] <smartboyhw> skaet, I wrote all the bugs we found in the release notes
[12:59] <smartboyhw> So we are fine
[12:59] <amjjawad> skaet: so, how can I do that without having access? :)
[12:59] <skaet> amjjawad, :-)  you can't, and we need to fix that.
[13:00] <amjjawad> skaet: ok, thanks!
[13:00] <amjjawad> skaet: anything from my side to be done? email to be sent or something?
[13:00] <smartboyhw> amjjawad, it's marked ready anyways
[13:00]  * skaet will look after she finishes some initial tasks,  and if she can't figure it out...  will ask stgraber.  :-)
[13:00] <smartboyhw> skaet, I think amjjawad has to join the Ubuntu GNOME Release Team or something
[13:00] <skaet> amjjawad,  are your release notes for UbuntuGNOME up to date
[13:01] <skaet> smartboyhw,  yes, its something like that.
[13:01] <smartboyhw> skaet, wait, amjjawad IS in the team
[13:01] <smartboyhw> amjjawad, are you logged in? -.-
[13:02] <amjjawad> skaet: I need to double check with jbicha, he already updated it
[13:02] <amjjawad> I was out of town and came back home last night with so bad migraine so trying to make my way without having migraine back
[13:03] <amjjawad> smartboyhw: of course I am logged in :)
[13:03] <smartboyhw> amjjawad, -.- sigh
[13:11] <skaet> JackYu, do you have any  feedback on the update testing for UbuntuKylin?
[13:11] <Laney> starting image publishing now
[13:12] <smartboyhw> Laney, \o/
[13:13] <smartboyhw> skaet, Laney BTW upgrades using images is NOT working
[13:13] <smartboyhw> http://launchpad.net/bugs/1220986
[13:13] <ubot2`> Launchpad bug 1220986 in ubiquity (Ubuntu) "On upgrade from image testcase ubiquity shows no upgrade option." [Undecided,New]
[13:13] <smartboyhw> (For both UbuntuKylin and Ubuntu Studio)
[13:13] <Laney> OK, make sure it's in your release notes
[13:14] <Laney> also that xnox knows ;-)
[13:14] <smartboyhw> Laney, I put it in Ubuntu Studio's release notes
[13:14]  * Laney has never actually tried an upgrade like that
[13:14] <smartboyhw> xnox, do take note of the bug:P
[13:17] <xnox> Laney: smartboyhw: that bug is invalid, see my comment on the bug.
[13:18] <smartboyhw> xnox, -.- But UbuntuKylin is failing the test too
[13:18] <smartboyhw> I think they need to report a seperate bug
[13:18] <smartboyhw> ypwong, JackYu maclin ^
[13:18] <xnox> Laney: smartboyhw: with multiple operating systems installed we do not provide upgrade option, as per design. As it's imposible to adequately present which one of the multiple ubuntu instlalations to upgrade.
[13:19] <skaet> phillw,  is there anyone working on getting results for Lubuntu desktop preinstall for armhf+ac100?  or do we drop it from the list?
[13:19] <Laney> The testcase should say this then
[13:19] <smartboyhw> skaet, ogra_ is working on it (I told him to do so:P)
[13:19] <xnox> smartboyhw: before filing upgrade bug, do check the tables in the design spec, as depending on what other installations are present there are various options present.
[13:19] <ogra_> working on what ?
[13:19] <smartboyhw> Laney, I will edit it soon.
[13:19] <smartboyhw> ogra_, you are testing the armhf+ac100 image of Lubuntu right>
[13:20] <ogra_> smartboyhw, i told you i'll do one test before final
[13:20] <smartboyhw> ogra_, ah OK
[13:20] <ogra_> i dont have the time to do beta testing
[13:20] <smartboyhw> So, dump it then?
[13:20] <xnox> smartboyhw: Laney: there are 8 typical variants of options available. and I'd rather not change the test-case as ideally we would do a matrix test of all 8 options, which is hard to cover/expose in the testcase.
[13:20] <ogra_> for beta ? yeah, just leave the daily around
[13:20] <maclin> xnox, you mean the upgrade option will be displayed only on a single OS?
[13:21] <Laney> xnox: The test cases can't tell people to do things that aren't allowed
[13:21] <Laney> That doesn't make sense
[13:21] <smartboyhw> skaet, phillw resigned yesterday as Lubuntu QA lead and Release Manager, so you will find difficulties in finding somebody to ACK -.-
[13:21] <xnox> maclin: https://docs.google.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/preview?pli=1#bookmark=id.35db66d9d3b3
[13:21] <skaet> smartboyhw,  ack.  ok, I'll mark it as not part of the release.
[13:21] <smartboyhw> skaet, sure
[13:22] <xnox> maclin: that's the table outlining when/which options should be shown. "Upgrade or Reinstall" should be available when there is only one ubuntu installation.
[13:22] <skaet> Laney,  ^ can you double check it isn't in the images you're pushing out?
[13:22] <Laney> it is not
[13:23] <skaet> Thanks Laney
[13:23] <Laney> I guess I should remove old alpha images at the same time
[13:26]  * skaet nods
[13:27] <maclin> xnox, I got it. Maybe we misunderstand the upgrade(image) testcase. we will do the test again,thanks:)
[13:37] <skaet> highvoltage, stgraber - what's the status of the release notes for Edubuntu?   ETA?
[13:40] <skaet> amjjawad, are all the Ubuntu GNOME release note edits done for your team?  or is there still some coming?
[13:43] <amjjawad> skaet: should be unless jbicha wants to add something else?
[13:46] <Laney> Do I need to build source images? If so, how?
[13:46] <cjwatson> cron.source
[13:48] <Laney> does the project matter?
[13:48] <skaet> jbicha,  any further updates to Ubuntu GNOME release notes from your perspective?
[13:48] <skaet> thanks amjjawad
[13:48] <amjjawad> skaet: at your service :)
[13:51] <smartboyhw> skaet, changed the Ubuntu Studio announcement link on the annoucement draft wiki page
[13:52] <skaet> Thanks smartboyhw  :-)
[13:57] <JackYu> skaet, hi, I was in a meeting just now. Did I miss something? BTW, the release notes for UbuntuKylin is ready.
[13:59] <skaet> JackYu,  Thanks.    The upgrade tests for UbuntuKylin haven't been marked as ready yet.  Anything we're waiting on from there?
[13:59] <jbicha> skaet: amjjawad: I think the UG release notes are fine
[13:59] <smartboyhw> skaet, we are waiting for maclin to complete the Upgrade (image) tests
[13:59] <maclin> xnox, I do the upgrade with 13.10 image to upgrade installed 13.04,but the upgrade option is disabled. There is only one 13.04
[14:00] <xnox> maclin: hm that's a bug. Can you open terminal / switch to tty1 with Ctrl-Alt-F1, to get the logs from within that run?
[14:00] <xnox> maclin: with $ ubuntu-bug ubiquity
[14:01] <JackYu> skaet, we could not open http://iso.qa.ubuntu.com/ since five hours ago:(
[14:01] <skaet> maclin - bug:1220986?
[14:01] <maclin> smartboyhw, I can't open the tracker page since 19:30
[14:01] <smartboyhw> maclin, I can
[14:01] <smartboyhw> Just refreshed
[14:01] <smartboyhw> maclin, JackYu did the Chinese government blocked the webpage?
[14:01] <smartboyhw> -.-
[14:01] <smartboyhw> Yep, full access whatsoever
[14:02] <smartboyhw> skaet, I will remove the amd64 upgrade testcase for Studio, I am blocked on doing it (not much bandwidth on internet in a VBox)
[14:03] <skaet> JackYu,  am able to access http?://iso.qa.ubuntu.com/  any thing you want me to update for you
[14:03] <skaet> ?
[14:03] <jbicha> skaet: bug 1220986 was marked invalid so should it be removed from the release notes?
[14:03] <ubot2`> Launchpad bug 1220986 in ubiquity (Ubuntu) "On upgrade from image testcase ubiquity shows no upgrade option." [Undecided,Invalid] https://launchpad.net/bugs/1220986
[14:03] <smartboyhw> jbicha, it is removed from mine
[14:03] <smartboyhw> Not sure on the main ones though:P
[14:04] <skaet> jbicha,  yup - doing.  thanks.
[14:06] <smartboyhw> Hmm, both maclin and JackYu went MIA
[14:06] <smartboyhw> Not good:(
[14:06] <smartboyhw> JackYu, welcome back:P
[14:06] <JackYu> skaet, we change another network and it works. We will finish it soon. Thanks.
[14:07] <skaet> JackYu,  :-)  Thanks!
[14:09] <xnox> FFe granted for eclipse-eclox bug #1220362
[14:10] <ubot2`> Launchpad bug 1220362 in Ubuntu "[NEW] [FFe] Sync eclipse-eclox 0.10.0-1 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1220362
[14:10] <smartboyhw> skaet, \o/ everything is ready:P
[14:10] <xnox> ScottK: ^ eclipse-eclox synced into new queue.
[14:19] <skaet> smartboyhw,  :-)
[14:20] <smartboyhw> skaet, waiting for your call:)
[14:21] <skaet> Laney, images are all signed off and ok to go now.   Let us know when we should start looking for them on the server and testing the links/etc.
[14:21] <Laney> cron.source is still running
[14:22] <skaet> ok.
[14:22] <Laney> oop, just finished
[14:22] <smartboyhw> LOL
[14:42] <Laney> skaet: just triggered the mirrors
[14:42] <skaet> thanks Laney
[14:42] <smartboyhw> I think we can release soon!
[14:43] <Laney> take a few minutes to sync up
[14:45] <skaet> smartboyhw,  working through the release notes and checking the links all working will take some time.
[14:45] <smartboyhw> skaet, sure;)
[14:46] <stgraber> Laney: if you care about bittorrent, you should wait around an hour
[14:46] <stgraber> (it's fine not to care)
[14:47] <Laney> yep
[14:47] <Laney> skaet's call at this point
[14:48] <skaet> stgraber, Laney - prefer that bittorrent is working
[15:14] <Laney> skaet: I'm getting data on xubuntu-13.10-beta1-desktop-amd64.iso now
[15:14] <Laney> torrent
[15:16] <skaet> Laney,  ok will start checking through the links
[15:17] <Laney> I'm seeding to myself
[15:17] <Laney> this is fun
[15:18] <Laney> s/seeding/whatever it's called when you haven't finished downloading/
[15:44] <smartboyhw> Laney, skaet: How is the checking going?
[15:45] <Laney> omgubuntu already announced the beta for us :-)
[15:45] <skaet> Laney,  typical\
[15:45] <skaet> :-P
[15:45] <smartboyhw> heh
[15:45] <smartboyhw> So it isn't officially announced by Ubutnu Release Team (yet)?
[15:46] <Laney> not until you see the mail
[15:46]  * smartboyhw does not know how fast can he see the mail:P
[15:46] <skaet> yup.
[15:50] <smartboyhw> Sigh, got to sleep now
[16:05] <skaet> stgraber, highvoltage - link isn't working for Edubuntu notes - do I have the correct one?   or should I just point to the Beta1/Edubuntu page?
[16:05] <skaet> smartboyhw,  thanks for your help getting this ready.   Sleep well.
[16:08] <Laney> Can someone please remove gst-libav1.0 from s-proposed?
[16:09] <skaet> stgraber, highvoltage: is http://www.edubuntu.org/news/13.10-beta1 the right link to use?
[16:11] <amjjawad> Funny what OMG Ubuntu is always trying to prove: https://www.facebook.com/omgubuntu/posts/660809390598268
[16:11] <amjjawad> I couldn't help it, I had to leave a tiny small note :)
[16:12] <stgraber> skaet: no idea, let me check
[16:12] <skaet> thanks stgraber.
[16:13] <stgraber> skaet: yep, looks right (even if it doesn't seem to exist)
[16:13] <skaet> stgraber,  any feel for when it can be made to exist?
[16:14] <stgraber> skaet: no idea, I don't really have time for this at the moment, so hopefully highvoltage can take care of it
[16:15] <skaet> stgraber, ack.   Let me know if you hear back from him,  its now on critical path for sending out the announce.
[16:17] <stgraber> skaet: I created a basic one now
[16:17] <cjwatson> amjjawad: OMG Ubuntu once removed my comments pointing out that they'd jumped the gun on a release announcement
[16:17] <skaet> thanks stgraber
[16:18] <stgraber> skaet: let me know when to mark it public
[16:19] <amjjawad> cjwatson: I'm not surprised but for me, I will keep posting and correcting the FUDs they are spreading :D
[16:19] <Laney> post it on a forum you control if you want to do that :P
[16:19] <cjwatson> amjjawad: (I was explicitly posting on behalf of the release team)
[16:20] <amjjawad> cjwatson: I had a word with them before
[16:21] <skaet> stgraber,  go ahead and mark it public.   Rest of flavors are visible.
[16:21] <amjjawad> I have also talked to web upd8 once because they have posted something incorrect as well about Lubuntu. Web Upd8 have edited their post and they did not remove my comments :)
[16:21] <skaet> all the links to the images seem to be working,  and that's the last link left.
[16:21] <amjjawad> but for OMG Ubuntu guys, they don't really reply your comments! at least, that what I've seen so far
[16:22] <xnox> cjwatson: i wonder if we can make a joke about OMG ubuntu in BetaFinal release announcement, to make their readers backslash at them ;-)
[16:23] <xnox> cjwatson: i did email Joey, why it's causing problems (e.g. for final release mirrors are not synced up)
[16:23] <stgraber> skaet: marking it public will immediately post it to planet ubuntu
[16:23] <Laney> stgraber: Can you take care of the gst-libav1.0 removal request I asked for ^ please?
[16:23] <Laney> (sorry to ping but general requests are going unanswered)
[16:24] <xnox> cjwatson: at least OMG don't blog about leaks, which is better than some Ubuntu Members.
[16:24] <cjwatson> xnox: Needling them is unlikely to be productive, I think
[16:24] <stgraber> Laney: sure
[16:25] <Laney> ty
[16:25] <stgraber> Laney: got a bug report?
[16:25] <Laney> nop, want one?
[16:25] <stgraber> please
[16:26] <stgraber> that makes it easier to figure out why something got removed later on (and avoids overly long removal comments)
[16:27] <Laney> k, didn't know if you cared for proposed
[16:27] <utlemming> I guess the bot doesn't supress the builk add any more....sorry :)
[16:27] <Laney> stgraber: bug #1221322
[16:27] <ubot2`> Launchpad bug 1221322 in gst-libav1.0 (Ubuntu) "Remove 1.1.3-1 from saucy-proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1221322
[16:28] <xnox> utlemming: there is a magic command to silence / unsilence the bot, but i don't remeber the syntax.
[16:29] <Laney> I thought it was supposed to buffer / abbreviate for mass build additions
[16:29] <stgraber> Laney: done
[16:29] <Laney> fanx
[16:30] <stgraber> the bot has flood protection, but if you're unlucky enough to push the builds while it's scanning, it sees them as two smaller batches and so skips the flood protection
[16:30] <xnox> cjwatson: hm. making locations 503 to general public? or will that block mirroring?
[16:30] <cjwatson> xnox: it would block mirroring and it's not worth it for the relatively minor irritation caused
[16:31] <xnox> ok.
[16:31] <cjwatson> or at least it could block some mirroring
[16:31] <cjwatson> and generally, I don't think we should inconvenience ourselves because people suck :)
[16:31] <cjwatson> for instance it's useful for us to be able to examine our own web pages pre-release
[16:32] <skellat> Any possible way to break the OMG download links?
[16:32] <skaet> ok,  announce email has been sent off...
[16:32] <stgraber> I think we had to publish a 301 to some html page once when slashdot announced a release before it happened, but in that case we had a check on the referrer and the links were pointing to the wrong ISO image to being with
[16:32] <skaet> stgraber,  go ahead and make your link public.
[16:33] <stgraber> skaet: done
[16:33] <xnox> yeah.... at my old workplace we special cased all employee sub-nets to allow viewing changes ahead of releasing the lockdown. Not feasible for a public project the size of Ubuntu =)
[16:33] <Laney> I'll re-cron and mark the milestone as released
[16:33] <xnox> \o/
[16:33] <Laney> utlemming: want to mark your cloud images as ready?
[16:33] <Laney> not sure what difference that makes, mind
[16:33] <cjwatson> skellat: it's not worth it
[16:33] <skaet> stgraber,  can you update the header for this channel and #ubuntu-devel?
[16:33] <stgraber> skaet: I can't, no ACL
[16:33] <Laney> you both can
[16:33] <Laney> no +t
[16:34] <stgraber> oh, good point
[16:34] <stgraber> skaet: you can do it yourself
[16:34] <skaet> stgraber,  I've got a password snag going, can't authenticate.
[16:34] <stgraber> skaet: don't need to
[16:34] <skaet> (or would have)
[16:34] <skaet> ?? ok trying
[16:34] <stgraber> skaet: the topic isn't protected in either channel
[16:35]  * skaet sees 12.04.2 should go to 12.04.3 and fixes at the same time.
[16:36] <skaet> coolio.  :-) that worked.
[16:37] <utlemming> Laney: yeah, I was just looking why my results for tests didn't land...working on that now
[16:37] <Laney> stgraber: will he still be able to update the status if the milestone is released?
[16:37] <Laney> I re-cronned and don't really want new builds to land there
[16:38] <Laney> Or I could just turn off build publication for that one
[16:38] <Laney> doing that
[16:40] <Laney> skaet: Think you picked up some whitespace damage in that email
[16:40] <skaet> Laney,   awe... drat.
[16:42] <skaet> yup did.   Resending to be  readable.
[16:43] <utlemming> Laney: okay, I think I marked them ready
[16:43] <Laney> utlemming: Great, thank you.
[16:43] <amjjawad> I have not noticed that before but I just had a look and every date on http://cdimage.ubuntu.com/ubuntu-gnome/releases/saucy/beta-1/ is 05-Sep-2013 except for the ISO files which is 03-Sep-2013 ... is that normal? as far as I remember, all the entries should be on the same day or maybe it is my rusty memory?
[16:44] <skaet> cjwatson,  can you reject the message waiting moderator approval in ubuntu-devel-announce?
[16:44] <amjjawad> did not yet had my coffee so :P
[16:44] <Laney> amjjawad: Some of them are made when the image is published and some when it is first built
[16:44] <amjjawad> so the MD5SUM which is dated 05-Sep-2013 will work for the image dated 03-Sep-2013 ??
[16:45] <Laney> You can see the same on e.g. http://cdimage.ubuntu.com/ubuntu-gnome/releases/raring/release/
[16:45] <Laney> right
[16:45] <amjjawad> Laney: I see, thanks a lot :) just to double check :D
[16:46] <skaet> cjwatson,  looks like I was able to cancel it directly.
[16:50] <infinity> xnox: Hrm.  Why does boost-mpi-source1.53 suddenly want to be in main?
[16:51] <xnox> infinity: there was a mistake in one of the upload, but all should be correct now, let me check.
[16:51] <skaet> Laney,  my test email to self came through ok.   trying again....
[16:51] <infinity> +Package: libboost1.53-all-dev
[16:51] <infinity> xnox: ^-- Perhaps because the metapackage moved?
[16:52] <xnox> infinity: that package was always in -mpi- package, no?
[16:52] <infinity> xnox: Oh, no.  Because libboost-graph-parallel1.53.0 moved.
[16:52] <infinity> xnox: And libboost-graph-parallel1.53.0 depends on libboost-mpi1.53.0
[16:52] <xnox> infinity: moved from where to where?
[16:52] <infinity> http://launchpadlibrarian.net/149409992/boost1.53_1.53.0-6%2Bexp2ubuntu2_1.53.0-6%2Bexp3ubuntu4.diff.gz
[16:52] <infinity> xnox: From mpi to the base package.  Check the debian/control diff.
[16:53] <skaet> Laney,  google mail is giving me woes...
[16:53] <xnox> infinity: right, which is wrong.
[16:53] <infinity> Err, wait.  Everything moved?  I'm so confused by this diff.
[16:54] <xnox> infinity: boost1.53 does not build graph-parallel, see https://launchpad.net/ubuntu/+source/boost1.53/1.53.0-6+exp3ubuntu4/+build/4928604
[16:54]  * skaet cancelled post to ubuntu-devel-announce again.
[16:54] <xnox> infinity: it does not produce said binary package, what does component missmatches analyse?
[16:54] <amjjawad> skaet: two emails? I guess they are the same, right?
[16:55] <infinity> xnox: I think c-m is unhappy because your .dsc is wrong because your debian/control is wrong.
[16:55] <infinity> xnox: https://launchpadlibrarian.net/149223980/boost1.53_1.53.0-6%2Bexp3ubuntu4.dsc
[16:56] <infinity> xnox: Your source package CLAIMS to build all the stuff from -mpi- and that throws the extra-include rescuing operations off.
[16:56] <xnox> infinity: yes my .dsc lists things it doesn't build.
[16:56] <infinity> xnox: Again, see the confusing diff.
[16:56] <infinity> xnox: Why did you change that?
[16:57] <xnox> infinity: makes it a two-liner to convert from boost -> mpi source package, instead of spending time reapply the pathches and carefully checking that nothing got lost.
[16:57] <xnox> infinity: plus it makes it suitable to be committed in debian, which I did.
[16:58] <xnox> infinity: ok, so i have to clean up my .dsc.
[16:58] <xnox> i guess such tricks are fine on gcc* packaging because well, it's all in main.
[16:58] <infinity> xnox: If you want to retain the 2-liner semantic, you'll probably want to switch to a control.in
[16:58] <xnox> yeap.
[17:00] <xnox> infinity: can I lie in .dsc? =) e.g. sed it before uploading =))) muahahaha
[17:00] <xnox> that would confuse everyone.
[17:01] <infinity> xnox: No.
[17:01] <Laney> skaet: bad
[17:02] <Laney> skaet: can you turn off HTML mail?
[17:02] <skaet> Laney,  yup,  no links then,  but... better than what we're seeing.
[17:02] <skaet> I'll send the test one to you before trying to post again.
[17:03] <Laney> it's fine how it was on the wiki
[17:03] <skaet> Yeah,  that was what was cut/pasted in.   google mailer fun.  :-P
[17:03] <infinity> That's some seriously unreadable email.
[17:04] <ogra_> not in a modern MUA
[17:04] <ogra_> :P
[17:04] <Laney> hey, mutt was uploaded this year
[17:05] <skaet> infinity,  yeah,  html mailers :-P   Looks fine in my inbox, but ....
[17:05] <ogra_> looks fine in evolution too
[17:05] <Laney> look at the list archive
[17:09] <infinity> ogra_: It only looks fine in a "modern" MUA because you're reading the HTML part.  The text part is universally ugly, no matter what you read it in. :P
[17:12] <infinity> On the other hand, I can't complain TOO much, because at least there IS a text part.
[17:12] <infinity> So, it beats the HTML-only email I get from, say, my bank. :(
[17:12] <skaet> Laney,  new test version on its way to you....   if that doesn't work,  I'll just give up on trying to have the links working.
[17:13] <ogra_> heh
[17:13] <Laney> I could send it ;-)
[17:14] <infinity> skaet: Why do you care about having HTML links?  Any decent MUA will auto-linkify http:// links in a text-only email on the client side.
[17:15] <skaet> Laney,  there are a couple of edits to what's on the WIKI page version needed.
[17:15] <skaet> Laney,  how did it look
[17:15] <Laney> sec
[17:16] <skaet> infinity,  was standard process to add them.   Complaints in the other direction before.
[17:16] <Laney> yes, looks fine now
[17:16] <infinity> "Standard process"?  None of the rest of us send HTML email.
[17:16] <skaet> Thanks Laney.  Ok,  keeping fingers crossed that 3rd time's a charm.
[17:19] <amjjawad> balloons: you there?
[17:25] <balloons> amjjawad, pong
[17:25] <amjjawad> hi balloons
[17:25] <balloons> hello
[17:25] <amjjawad> just to let you know, I am planning to post Kate's email on Ubuntu QA Social Sites
[17:26] <balloons> excellent, I wanted to share an easy link to all the images, but there's no master folder.. it's seperated by flavor
[17:26] <amjjawad> the more testers, the better ;)
[17:26] <balloons> :-)
[17:26] <amjjawad> Leave it to me
[17:26] <amjjawad> what happened to our master plan by the way? :P
[17:27] <balloons> it's still out there.. beta1 and tests failing took precedence
[17:27] <amjjawad> I did not forget it but I don't want to push hard, I know you are busy ;)
[17:27] <balloons> UGJ is coming up, as usual I'd like to try and do something; a good time to test out ideas
[17:27] <amjjawad> UGJ?
[17:34] <bdmurray> skaet: It just occurred to me that DevelReleaseAnnouncement was not updated to reflect the change from ALPHA to BETA.  I see it is on https://wiki.ubuntu.com/BetaProcess, is that the right wiki page?
[17:36] <skaet> infinity,  the HTML email was not intended and a result of using a new mail client.  Now know its an issue, and will check to avoid in future.   Adding the links to be hot links on the announce emails is something that's been done historically .  see: https://lists.ubuntu.com/archives/ubuntu-release/2012-September/001979.html
[17:38] <skaet> bdmurray,  yes,  but that page needs a good hard scrub as several things no longer apply this cycle that are being called for on it.
[17:38] <xnox> skaet: most email client auto-detect URLs and turn them into clickables, which includes all web email clients, desktop clients, mailing list archival websites and blogging engines.
[17:38] <infinity> skaet: That list archive post is just an example of what I was saying, that a decent client (in this case, the list archive software) will automatically linkify strings starting with "http://"
[17:39] <xnox> skaet: thus plain text emails are preferred (without multipart html portions )
[17:41] <skaet> infinity,  xnox - went through explicitly adding the links before for that one I pointed you at.   But if everyone is agreed it shouldn't be done in future,  then lets just make it explicit.
[17:48] <bdmurray> skaet: is somebody going to be doing that scrub of the BetaProcess page?
[17:51] <skaet> bdmurray,  I'll do a scrub this weekend then mail out for comments.
[17:51]  * skaet handling it as part of checklist
[17:52] <slangasek> skaet: please don't drop anything from that page without discussion.  Stuff already fell through the cracks last cycle because of the process pages not being followed.
[17:52] <skaet> slangasek, was thinking, I'd create a temp page,  let folks compare back and forth,  then merge.   ok?
[17:53] <slangasek> there's nothing on that page that should be dropped, and if the optional beta-1 is no longer the point that it should happen, we need to make sure we have some other way to make sure it happens at the appropriate time
[17:53] <slangasek> skaet: as long as things don't wind up dropped from the page before we've sorted out where they should go, fine
[17:54] <skaet> slangasek,  approach I was contemplating was a table,  with tick boxes depending if applicable or not.  Columns being for optional vs everyone.
[17:54] <skaet> hence,  scratch page to fuss on.   Agree very much don't want to accidently drop something.
[18:28]  * apw notes this is the xen update (for raring for now) under a recent preliminary MRE approved by the techboard
[19:20] <highvoltage> stgraber, skaet: thanks for taking care of those notes, I was out
[19:21] <highvoltage> (been hanging with Richard Stallman, of all people :p)
[21:00] <lool> Mighty release lords, please find a new FFE for gst-fluendo-mp3 https://bugs.launchpad.net/ubuntu/+source/gst-fluendo-mp3/+bug/1221434
[21:00] <ubot2`> Launchpad bug 1221434 in gst-fluendo-mp3 (Ubuntu) "FFE New upstream release" [Undecided,New]
[21:06] <infinity> lool: I'm offended by your test being in French.
[21:07] <infinity> lool: Approved, though.  Please close the bug in your changelog.
[21:07] <lool> thanks
[21:07] <infinity> (Or if you're syncing from Debian, close by hand, whatever)
[21:08] <lool> unfortunately, it will be in NEW in Debian for now
[21:08] <lool> due to new binary package
[21:16] <lool> infinity: ^ resulting binaries
[21:16] <lool> hmm missing armhf but coming
[21:17] <lool> there we go
[22:14] <slangasek> bdmurray: interestingly, the oldest unverified SRU in precise right now seems to be for bug #1122596, which you sponsored the upload of... seems like that's a bug people might like fixed, any idea how we can get it verified?
[22:14] <ubot2`> Launchpad bug 1122596 in libappindicator (Ubuntu Precise) "Race condition in app_indicator_init() causes application crash" [High,Fix committed] https://launchpad.net/bugs/1122596
[22:15] <bdmurray> slangasek: the test case mentions "we have many crashdumps"... I wonder where those are
[22:16] <bdmurray> if we had some crashes then we could look in errors for them
[22:26] <slangasek> bdmurray: seems that edit was from John Vert, who I guess is with Valve


[12:45] <dholbach> MOTU Q&A Session in 15 minutes!
[12:46] <Ng> dholbach: I had a question about debian/watch files for tracking Launchpad project downloads, but I found our very own hero jamesh had answered such a question on LP - question 21146 :)
[12:46] <rzr> dholbach: how long will it takes ?
[12:46] <Ng> seems like it might be useful for others
[12:47] <dholbach> rzr: roughly an hour
[12:47] <persia> This is the "How Not to Package" session, right?
[12:47] <dholbach> Ng: rock and roll - it might make sense to add that to the debian/watch recipe
[12:47] <rzr> ok then i'll stay here then :)
[12:48] <dholbach> http://wiki.ubuntu.com/PackagingGuide/Recipes
[12:48] <persia> Do we want to have a gobby for listing deprecated methods?
[12:49] <dholbach> I planned to just put them in my editor and go from there
[12:49] <Ng> dholbach: oki doki
[12:49] <dholbach> but if somebody wants to set up a gobby session, that's fine with me
[12:49]  * dholbach hugs Ng
[12:49] <persia> dholbach: OK.  Makes sense.  I'll feed you a list in about 5 minutes then, and let you lead :)
[12:49] <dholbach> nice
[12:55] <db-keen> It looks to me like a .deb can be of multiple compression formats, how do you know which one it is?
[12:56] <rzr> db-keen: man file  ?
[12:57] <stdin> isn't .deb just an ar archive with 3 files in it, 2 being tar.gz's?
[12:58] <minghua> Not necessarily tar.*gz*.
[12:58] <minghua> You can always use "ar t" to check, of course.
[12:58] <Amaranth> it's not tar either, is it?
[12:58] <persia> .deb is a "ar" file, containing several compressed files, where the compression format can be any of a number of things.
[12:59] <persia> Each file when decompressed is a tarball, containing some portion of the package.
[12:59] <Amaranth> that one always gets me, tar vs ar
[12:59] <dholbach> hello everybody - welcome to another MOTU Q&A session! Let's start with our usual round of introductions!
[12:59] <minghua> Inside the .deb?  Three files, debian-binary (a plain text file), control.tar.gz and data.tar.gz.
[13:00]  * dholbach is Daniel Holbach, member of the MOTU team and trying to make becoming a MOTU as enjoyable and straight-forward as possible - if you have any ideas, let me know :)
[13:00] <minghua> The data.tar.gz can use other compression formats.
[13:00]  * persia is Emmet Hikory, member of MOTU, and interested in making sure those who aren't MOTU have as little difficulty contributing as possible
[13:00] <dholbach> db-keen: you can use something like         DEB_DH_BUILDDEB_ARGS := -- -Zbzip2               in debian/rules to use bz2 compression
[13:00] <rzr> it's time children !
[13:01] <dholbach> who else do we have here?
[13:01]  * rulus is Roel Huybrechts, and is just listening to learn more about Ubuntu packaging and the MOTU team
[13:01] <dholbach> ahh, pedro_! :)
[13:01] <dholbach> welcome rulus
[13:01] <rulus> thanks :)
[13:01] <pedro_> heey dholbach ;-)
[13:01]  * Amaranth is Travis Watkins, driveby MOTU guy
[13:02] <dholbach> pedro_ is Pedro Villavicencio - the GNOME Desktop Bug King
[13:02] <Amaranth> All hail pedro_
[13:02] <dholbach> :-)
[13:02]  * minghua is Ming Hua, MOTU member, another drive-by.
[13:02] <dholbach> I'm happy we have a lot of people here today (even if they didn't introduce themselves yet..... :-))
[13:03]  * rzr is Philippe Coval who packaged a few apps and is here because he's got time for
[13:03]  * Kmos is Marco Rodrigues, a MOTU helpful.
[13:03] <Kmos> :)
[13:03]  * amarillion is Martijn van Iersel, trying to learn as much about packaging as he can
[13:03] <dholbach> welcome Kmos, rzr and amarillion
[13:03] <pedro_> haha
[13:03] <dholbach> great to have you all here
[13:03]  * pedro_ hugs dholbach
[13:03] <Kmos> dholbach: always ready :)
[13:03] <dholbach> so nenolod proposed the following for today's Q&A Session: "<nenolod> dholbach, one suggestion for your MOTU Q&A sessions would be to go through how to NOT make a debian package"
[13:04] <Amaranth> Make an rpm? :P
[13:04] <txwikinger2> hi dholbach: Happy New Year
[13:04] <dholbach> so what I'd like us to do in the first five minutes of the session is: collect crackful ideas how to make the most broken, awful and horrific package possible
[13:04] <dholbach> thanks a lot txwikinger2
[13:04] <dholbach> and the same to you
[13:04] <Amaranth> dholbach: run autofoo in the build
[13:04] <persia> autoconversions from ebuild, rpm, etc.
[13:04] <Amaranth> automake, autoconf, etc
[13:04] <dholbach> after that we should take the time to find out how to NOT do that :)
[13:05] <amarillion> making a binary package directly...
[13:05] <rzr> or explain apt-build ?
[13:05] <dholbach> ok... go wild! I'm taking notes
[13:05] <dholbach> what else?
[13:05] <Amaranth> making a package that has a python rules file ;)
[13:05] <txwikinger2> recursive patching?
[13:05] <rzr> are there pple from gentoo project around ? It would be nice to have a gentoo collaboration group if none exists already
[13:06] <persia> mixing patches in diff.gz and debian/patches
[13:06] <dholbach> what else? what makes it horrible for users?
[13:06] <dholbach> what makes it horrible for other developers?
[13:06] <dholbach> what makes it horrible for archive admins?
[13:06] <minghua> persia: I wouldn't say it's a terrible thing, as long as the patches are on different areas.
[13:06] <persia> deleting all the settings, and reconstructing from scratch in the maintainer scripts
[13:06] <Amaranth> unneeded dependencies
[13:06] <dholbach> good ideas... keep them coming :)
[13:07] <persia> minghua: I've hit conflicts before with it, and unwinding was unpleasant.
[13:07] <Amaranth> making a package that build-deps on all of gnome and all of kde (oops, i did that)
[13:07] <Amaranth> :P
[13:07] <minghua> persia: Right, sucks for mergers, I suppose.
[13:07] <dholbach> no copyright information - dodgy stuff "from the net"
[13:07] <txwikinger2> download things from different places inside debian/rules
[13:08] <dholbach> no docs at all, no manpages
[13:08] <Amaranth> txwikinger2: well, no, that has good uses
[13:08] <Amaranth> manpages? who needs those? :)
[13:08] <txwikinger2> code is self-documenting :D
[13:08] <persia> checkinstall, dbs, yada, debmake
[13:08]  * Amaranth stabs yada a million times
[13:08] <rzr> nothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :)
[13:09] <persia> Access the internet at build-time
[13:09] <txwikinger2> fail install script because db does not exist
[13:09] <Amaranth> interactive builds
[13:09] <compwiz18> is using dpkg -b to build a package a good idea/bad idea?
[13:09] <persia> interactive installs
[13:09] <persia> compwiz18: That falls under "making a binary package directly..."
[13:09] <Amaranth> an interactive build took out the buildds recently, didn't it?
[13:09] <dholbach> lots of useless cruft in the package
[13:10] <rulus> missing .desktop file for a graphical application
[13:10] <txwikinger2> icons in wrong places
[13:10] <dholbach> missing files in the package
[13:10] <persia> rulus: There were 237n of those last I checked, so maybe less critical (but yes).
[13:10] <Amaranth> installing to /opt
[13:10] <amarillion> What is yada and why is it so bad? (Or is this not the place to ask that?)
[13:11] <persia> amarillion: Don't ask.  Don't google.  Don't even look.  You will be happier.
[13:11] <dholbach> software without active upstream
[13:11] <dholbach> inactive maintainer, no bug triage
[13:11]  * persia likes software without active upstream, if it is stable and well written.
[13:11] <amarillion> dholbach, but what if the software is finished?
[13:11]  * rzr reads http://yada.alioth.debian.org
[13:11] <rulus> (software is never finished?)
[13:11]  * Kmos dies
[13:12] <Amaranth> why does the yada webpage talk about making lobster?
[13:12] <dholbach> ok... shall we close our selection for this time around?
[13:12] <Kmos> rulus: now, you need to be purified..
[13:12] <Kmos> dholbach: move on =)
 dholbach: run autofoo in the build
 automake, autoconf, etc
[13:12] <dholbach> was the first ones we had
[13:13] <Amaranth> ok, should I explain?
[13:13] <dholbach> Why can this be problematic?
[13:13] <dholbach> Amaranth: great, go ahead
[13:13] <txwikinger2> because of different versions of autofoo....
[13:13] <Amaranth> Running automake or autoconf in the buildd can cause build failures due to different versions, a different environment, etc
[13:13] <txwikinger2> ?
[13:13] <Amaranth> err, in the build
[13:14]  * txwikinger2 currentlu has this problem... work on ubuntu but not on debian
[13:14] <Amaranth> From my experience no two computers will ever produce the same output from running autoconf
[13:14] <dholbach> are there cases in which it might be necessary to run any of the autotools again and how would you deal with those?
[13:15] <Amaranth> If you need to update the configure script or Makefiles to update dependencies and such you should update their configure.ac and Makefile.am counterparts then run automake or autoconf locally and put the diff between the new output and the original in a patch
[13:16] <dholbach> does this make sense to everybody? do we have any questions about that?
[13:16] <minghua> I disagree.  I think it's very reasonable to run autotools when build if you do it right.
[13:16] <rzr> Amaranth: remove generated files on make clean will help ? is it mandatory ?
[13:17] <txwikinger2> well... do you need to run autoconf if you change the architecture?
[13:17] <dholbach> one example that come to my mind are Launchpad Integration in the GNOME packages (report bug to launchpad, etc)
[13:17] <txwikinger2> Isn't the problem if version-related files are part of the package?
[13:17] <minghua> To do it right, you need to build-depend proper version of autotools packages, and build-conflict troublesome ones.
[13:17] <dholbach> speaking of the devil, seb128 the king of launchpad-integration and auto* patches is here :-)
[13:18] <Amaranth> We do it in compiz to add a dependency on X cursor stuff for cursor theme support
[13:18] <Amaranth> add the check to configure.ac, add the linker stuff to the Makefile.am, run autoconf and automake, diff the new versions to the old ones, dump the output into a patch, now we have our updated build system and the builder doesn't have to worry about it
[13:19] <Amaranth> minghua: Of course it can be done but it's basically always better if you don't
[13:19] <dholbach> I think the best way to avoid this is to add an option for whatever changes you need in the configure.ac/Makefile.am files and get it upstream :)
[13:19] <Amaranth> Of course, but sometimes such things aren't possible :)
[13:20] <dholbach> minghua and Amaranth both have points and it can be problematic
[13:20] <dholbach> but it's probably not the first problem new contributors will run into :)
[13:20] <dholbach> persia mentioned: <persia> autoconversions from ebuild, rpm, etc.
[13:21] <dholbach> we have this every now and then, that dodgy ".deb files" turn up on blogs, the forums and other places that were produced that way
[13:21] <dholbach> which is why we only review source packages and not .deb files that went through some mystic conversion process
 making a binary package directly...
[13:21] <dholbach> ^ means the same
[13:21] <persia> alien is a great tool, and useful for an admin, but the resulting packages rarely have the right dependencies, and may be missing other useful bits.  Best to create the binary packages from a .dsc based source, rather than srpm or ebuild (which are both source formats).
[13:22] <dholbach> *nod*
[13:22] <dholbach> thanks persia
 making a package that has a python rules file ;)
[13:22] <Amaranth> Stick with the standard stuff, basically
[13:23] <dholbach> it's best to try to keep the debian/rules file as simple and understandable as possible
[13:23] <Amaranth> Just because you think it's cool to make the package in a 'special' way doesn't mean the next person to touch it will agree with you
[13:23]  * txwikinger2 giggles
[13:23] <dholbach> Makefile and shell elements are pretty common
[13:23] <rzr> and if python break you can not build anything ..
[13:23] <persia> No.  Makefile and shell elements only look similar
[13:24] <dholbach> persia: what do you mean?
[13:24] <Amaranth> debian/rules is a Makefile, if you disagree with this you're probably a somewhat advanced packager :)
[13:24] <minghua> There is a proposal to mandate debian/rules as a Makefile in Debian Policy, IIRC.
[13:25] <persia> dholbach: Trying anything tricky in a shell in a Makefile is likely to cause issues.  Similarly, shell scripts handle recursion and parallel execution poorly.
[13:25] <persia> I don't think it is good to conflate them, although much of the syntax is similar.
[13:25] <persia> Anything run outside $(shell $(COMMAND)) is unlikely to have the expected behaviour.
[13:26] <dholbach> right
 recursive patching?
[13:27] <txwikinger2> You asked me to be wild
[13:27] <txwikinger2> To write a patch that patches a patch :D
[13:27] <Amaranth> This is a horrible thing to do
[13:28] <Amaranth> Just apply the first patch, make your changes, make a patch from that, and make sure the first patch gets applied before this new one
[13:28] <txwikinger2> well exactly
[13:28] <dholbach> patches can depend on others, that's why a lot of packages use enumeration for patches in debian/patches
[13:28] <Amaranth> 01change-foo
[13:28] <Amaranth> 02change-foo-more
[13:29] <persia> Even so, it makes unwinding and feeding upstream difficult.  Also it's a common mistake from using foo-edit-patch blindly.
[13:29] <Amaranth> Right, ideally you shouldn't have any patches at all, they should all go upstream as soon as possible
[13:29] <dholbach> agreed :)
[13:29] <dholbach> persia and minghua had some more ideas about patching:
 mixing patches in diff.gz and debian/patches
 persia: I wouldn't say it's a terrible thing, as long as the patches are on different areas.
 minghua: I've hit conflicts before with it, and unwinding was unpleasant.
 persia: Right, sucks for mergers, I suppose.
[13:29] <persia> Sometimes you need a local patch (see e.g. the man-db package).
[13:29] <rzr> do you also use enumeration with quilt patch system ?
[13:30] <Amaranth> rzr: You don't have to (it keeps a list of the order) but you should anyway to make it obvious what goes where
[13:30] <rzr> yea the series file..
[13:30] <Amaranth> we use quilt in compiz but our patches are still 01foo, 02foo, etc
[13:30] <Amaranth> (btw, i think we have like 20 patches :/)
[13:31] <minghua> Does any patch system rely on the enumeration for the order?  Dpatch has a 00list file to record the order, too.
[13:31] <Amaranth> Another thing to not do: Learn best practices from the compiz patch
[13:31] <Amaranth> minghua: cdbs
[13:31] <Amaranth> err, from the compiz package
[13:32] <seb128> simple-patchsys he means, cdbs can use any dpatch, simple-patchsys or quilt depending of what is listed in the rules
[13:32] <Amaranth> well, yeah, but is simple-patchsys used anywhere else?
[13:32] <Amaranth> should be specific though
[13:33] <dholbach> door bell - sorry
[13:33] <dholbach> brb
[13:33] <Amaranth> It's a bomb!
[13:33] <txwikinger2> It's M$
[13:33] <seb128> dunno, but you can use cdbs without using simple-patchsys so saying cdbs is not right
[13:33] <persia> I believe simple-patchsys is only available with CDBS
[13:33] <Amaranth> Right, I just forgot the name :)
[13:34] <persia> OK.  Next up: <Amaranth> unneeded dependencies
[13:34] <Amaranth> This tends to happen when first making a package or when updating it to a new version
[13:34] <Amaranth> Make sure the dependencies listed for the package are actually needed, otherwise people have to install things they don't need
[13:35] <persia> What is a good way to check?
[13:35] <Amaranth> hmm, i don't really know
[13:35] <Amaranth> Usually when a new release is made they mention new and dropped dependencies
[13:36] <persia> For compiled packages, you can check to make sure the libraries are compiled in by looking at the -l calls in the build log (and there's a better way with objdump, with which I'm insufficiently familiar).
[13:36] <persia> For scripting languages, you can look for #include lines (or the equivalent) in the source files.
[13:36] <persia> Anyone have any other suggestions?
[13:36] <Amaranth> i check ldd for binaries
[13:37] <rzr> nm too ?
[13:37] <persia> ldd and nm are good.
[13:37] <persia> Next up: <txwikinger2> download things from different places inside debian/rules
[13:37] <Amaranth> of course nm doesn't work on stripped binaries
[13:38] <persia> Amaranth: Should still list symbols for shared library access, no?
[13:38] <seb128> what is that thing about dependencies?
[13:38] <Amaranth> doesn't look like it, running it on /usr/bin/compiz.real gives no output
[13:39] <persia> seb128: Ways to check to make sure the package really depends on things listed in Depends:
[13:39] <minghua> If you use ${shlibs:Depends}, there shouldn't be anything missing (unneeded, perhaps) library in the dependency, should there?
[13:39] <Amaranth> We're talking about listing things that aren't needed
[13:39] <rzr> Amaranth: readelf -a is verbose
[13:39] <seb128> well, libraries are usually automatically listed
[13:40] <minghua> Then ldd won't work either.
[13:40] <seb128> why do you want to use ldd?
[13:40] <minghua> dh_shlibdeps should give warnings these days anyway.
[13:40] <seb128> right
[13:40] <amarillion> maybe the simplest way is just removing them one by one and trying with pbuilder
[13:40] <seb128> and that's not a packaging question
[13:40] <amarillion> this could be automated
[13:41] <rzr> Amaranth: about foo.real <= is the .real suffix mentioned in some policy somewhere ?
[13:41] <Amaranth> rzr: For compiz we have a wrapper script to make sure it starts correctly so the actual binary gets moved to compiz.real
[13:42] <Amaranth> Not sure if there is some policy on this
[13:42] <rzr> Amaranth: I guessed that , but why call it .real or .bin or .elf ?
[13:42] <Amaranth> nothing else on my system has a .real version so i dunno
[13:42] <Amaranth> i know firefox has firefox-bin
[13:43] <rzr> I was wondering about that while building a native version of tuxguitar
[13:43] <persia> OK.  So, let's look at the next one.   <txwikinger2> download things from different places inside debian/rules
[13:43] <rzr> ...
[13:44] <txwikinger2> well.. what happens if the download place disappears
[13:44] <rzr> persia: you can merge this one with access to the internet at build time
[13:45] <persia> txwikinger2: That's one part.  The other being that the buildds don't have internet access :)
[13:45] <txwikinger2> :)
[13:45] <persia> rzr: Doing that.  Thanks.
[13:45] <rzr> txwikinger: or be spoofed ?
[13:45] <persia> txwikinger2: Any suggestions on how to work around that at packaging time?
[13:45] <txwikinger2> I think all necessary stuff should be part of the orig tarball
[13:45] <rzr> txwikinger2: but in case they can not be distribuated ...
[13:46] <Amaranth> That's install time though, not build time
[13:46] <Amaranth> like flashplugin-nonfree
[13:46] <persia> Also, sometimes there are out-of-tree patches maintained somewhere else that are interesting to include.
[13:46] <rzr> I dont see any alternative than a wrapper script like swf etc
[13:46] <Amaranth> If you need to install something at build time that is not redistributable then you should just not package such things
[13:46] <txwikinger2> if buildds can't get it, it must be part of the package
[13:47] <Amaranth> Downloading things at install time can be alright, although this is (i think) really only for flash
[13:47] <persia> Right.  So you make sure to include it in the package.  In orig.tar.gz if you must, or in diff.gz if upstream ships an otherwise clean orig.tar.gz.
[13:47] <rzr> do we have some package like that already ? why for ?
[13:48] <persia> rzr: Like which?
[13:48] <rzr> which need to dl stuff at compilation time
[13:49] <minghua> Amaranth: Another existing example is the MS web core fonts.
[13:49] <Amaranth> ah, right
[13:49] <rzr> binaries only tough
[13:49] <persia> rzr: Some example packages are those that use python ezinstall to download dependencies at build time.  CPAN, gems, etc. are also sometimes issues.
[13:49] <txwikinger2> rzr the germinate stuff cannot be automated because of it
[13:49] <rzr> oh yes I forgot them
[13:49] <Amaranth> rzr: What package can you think of that would need to download something from the internet at build time?
[13:50] <Amaranth> gems and such should simply be packages so you can build-dep on them properly
[13:50] <dholbach> those people listening in today? were there any items discussed that you had problems understanding?
[13:51] <dholbach> ok... seems to be all clear then :)
[13:51] <persia> Amaranth: Yes, but it's an unfortunately common mistake, even in Debian sometimes (given the frequency with which arch:all packages are autobuilt)
[13:51] <rzr> dholbach: beside your question it's ok for me :)
[13:51] <dholbach> :-)
 no docs at all, no manpages
 manpages? who needs those? :)
 code is self-documenting :D
[13:52] <Amaranth> Alright then
[13:52] <rzr> I just thought
[13:52] <Amaranth> Even desktop applications should at least have a manpage explaining what they are and what (if any) command line arguments they take
[13:52] <rzr> it should be easy to parse foo --help and generate a template man page isnt it ?
[13:52] <Amaranth> For example, the alacarte manpage just says what alacarte is
[13:53] <Amaranth> and it's horrible, so don't ever look at it :)
[13:53] <rulus> Should manpages be translated?
[13:53] <dholbach> it's not only about manpages... sometimes the upstream tarball ships documentation that is not installed into the package
[13:53] <dholbach> the same goes for example code
[13:53] <rzr> can man page be too documented ?
[13:54] <Amaranth> a man page is documentation
[13:54] <persia> rulus: That is nice, but at least including English as a base is best.  See http://qa.ubuntuwire.com/lintian/reports/Tbinary-without-english-manpage.html for some example packages that missed that, and an explanantion why it isn't ideal.
[13:54] <dholbach> rzr: I don't think it happens very often :)
[13:54] <rulus> persia: thanks :)
 nothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :)
[13:55] <dholbach> good point
[13:55] <dholbach> what you can do is run    dh_install --list-missing   in the directory of the local build
[13:55] <Amaranth> wow, i think i should be taking notes :)
[13:55] <dholbach> it will list all the files that are not installed into a package (especially in cases like rzr pointed out: where you have more than one binary package)
[13:56] <Amaranth> i forgot about dh_install --list-missing
[13:56] <minghua> Amaranth: Need help on alacarte man page?
[13:56] <dholbach> it's a great tool
[13:56] <Amaranth> minghua: I don't think I really need anything else but if you want to spruce it up a bit go for it
[13:56] <dholbach> you can also run     debc    in the local build directory to find out which files are installed in which package
[13:56] <Amaranth> ok, now i'm taking notes, i do all this junk manually :)
 fail install script because db does not exist
[13:57] <minghua> Amaranth: I'll probably give it a try.  Will let you know either way.
[13:57] <dholbach> txwikinger2: can you say a bit more about this?
[13:57] <txwikinger2> well.. there are often webapps that work with a db
[13:58] <txwikinger2> when the db does not exist, they just fail and leave a faild-package in apt
[13:58] <dholbach> right, they usually deal with those DBs in the postinst/prerm scripts, right?
[13:58] <txwikinger2> yes
[13:59] <dholbach> broken postinst/prerm scripts are a big problem for exactly the reason that txwikinger2 points out
[13:59] <dholbach> if you're not careful enough, they will break the installation of your users
[13:59] <Amaranth> oh man, prerm is the worst
[13:59] <dholbach> upgrade processes etc
[13:59] <Amaranth> well, and postrm
[13:59] <dholbach> ask mvo about it, he has a lot to say about the topic :)
[14:00] <dholbach> ok... it's time to close the session - thanks everybody for joining in
[14:00] <Amaranth> it sucks not being able to remove a package and getting your dpkg stuck an such a state
[14:00] <dholbach> thanks persia for taking over
[14:00] <persia> Being too agressive about update-alternatives and update-rc in maintainer scripts is frustrating as well.
[14:00] <dholbach> I had a great time and I hope you did too
[14:00] <Amaranth> Has good, thanks to dholbach and persia for running this
[14:00] <minghua> Yeah, thanks dholbach and persia.
[14:00] <Amaranth> err, Was
[14:00] <txwikinger2> \o/ dholbach
[14:00]  * Amaranth needs sleep
[14:01]  * dholbach hugs y'all
[14:01] <persia> Amaranth: There are logs, so you can keep them if you want :)
[14:01] <rzr> yea thx all , that was my 1st course, i'll manage to be there on next one ..
[14:01] <dholbach> see you all next week :)
[14:02] <persia> rzr: Also feel free to ask questions in #ubuntu-motu at any time.  There's less guarantee of an answer, but people may have time to get more in depth (I've seen 2-hour sessions spontaneously erupt on a single interesting issue).
[14:02] <Amaranth> Those are fun
[14:02] <Amaranth> I learned most of what I know from watching such things :)
[14:03] <rzr> try manpages too :)
[14:03] <Amaranth> man dh_* is good too
[14:10] <rzr> !topic + https://wiki.ubuntu.com/ClassroomTranscripts ?
[14:25] <santiago-ve> Hello!


[10:31] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Enabling simple, cost-effective Kubernetes on IBM Z with MicroK8s @ https://ubuntu.com//blog/enabling-microk8s-on-ibm-z
[11:35] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 724 @ https://fridge.ubuntu.com/2022/02/28/ubuntu-weekly-newsletter-issue-724/ (by guiverc)
[13:27] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Pacific Textiles drives digital transformation with new infrastructure for legacy and c... @ https://ubuntu.com//blog/pacific-textiles-drives-digital-transformation-with-new-infrastructure-for-legacy-and-cloud-native-applications
[23:41] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: This GNOME Extension Puts Dock Items Back in the App Grid @ https://www.omgubuntu.co.uk/2022/03/this-gnome-extension-puts-dock-items-back-in-the-app-grid (by Joey Sneddon)