[00:00] <Bachstelze> I haven't looked at all of them but that's probably why we hase so many FTBFSs
[00:00] <Bachstelze> packages that used to build fine but don't with the new toolchain
[00:00] <Bachstelze> have*
[00:01] <Bachstelze> awesome, it works
[00:02] <Bachstelze> I guess I should forward it to Debian since we haven't diverted
[00:02] <Bachstelze> not sure they'll accept it, though, it works fine for them apparently
[00:23] <ari-tczew> Bachstelze: lucas__ page shows packages which have been built fine in the past. now if you'd build on natty toolchain, result is fail
[00:23] <ari-tczew> so you're right
[00:23] <ari-tczew> how to deal SRU with backports?
[00:23] <ari-tczew> which version shall I choice?
[00:24] <ari-tczew> (0.6-0ubuntu2~maverick1) maverick-backports -> (0.6-0ubuntu2.1) maverick-proposed is OK?
[00:26] <ebroder> ari-tczew: I don't understand the question. Are you asking about making an SRU from a backport, or making a backport from an SRU?
[00:26] <ari-tczew> ebroder: this second
[00:26] <ari-tczew> ebroder: no, stop
[00:26] <ari-tczew> wrong
[00:27] <ari-tczew> ebroder: clementine is backported package. I want to push a SRU
[00:27] <ari-tczew> for maverick
[00:27] <ebroder> backports are separate from the SRU process, and we usually don't use backports as the basis for an SRU because SRUs should have minimal patches
[00:27] <ebroder> If the backport is buggy, then fix it in the dev release and get a new backport
[00:29] <ari-tczew> ebroder: lol, I have minimal patch for SRU
[00:29] <Bachstelze> debian 608011
[00:29] <ebroder> ari-tczew: I'm afraid you're still not making sense to me
[00:29] <Bachstelze> do we wait to see if they apply it, or create an ubuntu1 for now?
[00:30] <ari-tczew> ebroder: imagine (theory) that dev release has a big upgrade and you want to backport it. not always it's possible then we should get minimal patches.
[00:30] <ari-tczew> Bachstelze: you can wait a couple of days since we have devel distro.
[00:31] <Bachstelze> ok
[00:31] <Bachstelze> I'll create a bug on P and link it
[00:31] <Bachstelze> LP*
[00:31] <ebroder> ari-tczew: There is always a minimal patch to fix a bug. It may be a big patch, but it should still be minimal. It may be the same as the difference between two releases, but it should still be minimal
[00:32] <ari-tczew> Bachstelze: however, in bugtitle 'in ubuntu natty' is not 100% cool. better is use bugtitle like 'sendmail: FTBFS with binutils-gold and linking in gcc 4.5'
[00:32] <ari-tczew> Bachstelze: and please attach in Debian mail only patch to fix bug. no full debdiff
[00:32] <ari-tczew> Bachstelze: or maybe if you want prepare NMU, you should follow with Debian policy
[00:34] <ari-tczew> ebroder: in clementine case backport is possible way, but in my last sentence I gave only an example
[00:34] <Laney> that is not really NMUable
[00:35] <Laney> and it should be severity wishlist or minor
[00:35] <ari-tczew> ebroder: should do I open a new bug?
[00:36] <ari-tczew> (for backport)
[00:38] <ari-tczew> ebroder: if you want to writer YES, I tell that this is bureaucracy
[00:38] <ari-tczew> write*
[00:38] <ebroder> ari-tczew: I still can't understand what it is you're trying to do
[00:38] <ari-tczew> ebroder: ...
[00:39] <ari-tczew> ebroder: I _ want _ to _ fix _ a _ bug _ in _ backported _ package _ called _ clementine _ which _ exist _ in _ maverick-backports
[00:39] <ebroder> Thank you! That's what I was trying to figure out
[00:39] <ebroder> Ask for a new backport
[00:40] <ari-tczew> ebroder: what do you mean ask? open bug? open question on LP?
[00:40] <ebroder> Open a backport bug
[00:41] <ari-tczew> this is a joke
[00:42] <ari-tczew>  /usr/bin/ranlib: libclementine_lib.a: No space left on device
[00:42] <ari-tczew> I have 2GB free on part
[00:50] <Bachstelze> wvdial: same thing
[00:51] <Bachstelze> yay for easy karma \o/
[00:52] <Bachstelze> actually that's not going to give me much karma if everything must be forwarded to debian, eh
[00:56] <Bachstelze> ari-tczew: is it cool to say in the body of the message that the bug can be seen on Natty?
[00:57] <Laney> Bachstelze: getting stuff fixed in Debian gives you more karm
[00:57] <ari-tczew> if current binaries built fine, no
[00:57] <Laney> at least in my eyes
[00:57] <ari-tczew> Bachstelze: don't worry about numbers
[00:57] <Bachstelze> that was a joke ;)
[00:58] <Bachstelze> ari-tczew: so what exactly should I put then?
[00:59] <ari-tczew> Bachstelze: in mail forwarding to BTS?
[00:59] <Bachstelze> yeah
[00:59] <Laney> you can say that you found this problem when building for Ubuntu, and that the fix is in the attached patch
[00:59] <Laney> and politely ask them to apply it
[01:04] <ari-tczew> Bachstelze: http://paste.ubuntu.com/547622/
[01:08] <Bachstelze> ari-tczew: thanks
[01:10] <ari-tczew> Bachstelze: You're welcome.
[01:11] <ari-tczew> ebroder: saying gentle, I'm don't respecting rules and I'm trying to backport package using one bug.
[01:11] <ari-tczew> s/don't/not
[02:56] <Bachstelze> another one down
[02:56] <Bachstelze> guess I'll get some sleep, 'night folks
[03:01] <Bachstelze> bug 694398 if nyone is interested to sponsor it
[06:11] <udienz> [ftbfs] one down.. bug 694413
[06:16] <micahg> udienz: could you also upstream your patch to debian 554370 with teh appropriate tags: https://wiki.ubuntu.com/Debian/Usertagging
[06:18]  * micahg goes to test build firestarter, thanks for the patch udienz
[06:19] <udienz> micahg, Thanks! I think it's better when this patch is done reviewed by ubuntu-sponsors
[06:20] <micahg> udienz: yeah, oops, I spoke too soon, it should be a patch, not applied directly to source
[06:21] <micahg> I'll comment in the bug
[07:04] <udienz> micahg, Done, i have submitted again. and already tested via natty pbuilder
[07:08] <micahg> udienz: usually we just use the next number available for patches unless it needs to be at the end (like autoreconf)
[08:22] <udienz> micahg, soorry for delay reply. i will uploaded again and renaming it
[08:23] <micahg> udienz: it's ok, I've made the cahnges and added the patch name to the changelog
[08:23] <micahg> I'm testing it now
[08:31] <micahg> udienz: I'll upload in several hours, I don't like to upload right before bed
[08:31] <udienz> micahg, ok no problem
[08:31] <micahg> udienz: thank you for the patch
[08:32] <udienz> micahg, :) thanks for reviewing
[12:22] <dnivra> is this the channel where i can ask for packaging support?
[12:23] <ari-tczew> dnivra: yes. also exist #ubuntu-packaging
[12:24] <dnivra> ari-tczew: #ubuntu-packaging it is then. thanks!
[15:33] <ari-tczew> ScottK: I encourage you to consider about approve some devs from community, like micahg or ebroder
[15:33] <ari-tczew> and clean up 'pending approval' from bots ;)
[15:44] <micahg> apachelogger: sorry about the firefox installer override being dropped, I'll add it back
[15:44] <apachelogger> micahg: thanks :)
[15:44] <micahg> are LDFLAGS fixes ok as a patch as opposed to being overridden in debian/rules?
[15:53] <geser> LDFLAGS fixes?
[15:53] <micahg> geser: LDFLAGS additions
[15:53] <geser> like?
[15:54] <micahg> bug 694413
[15:55] <geser> I didn't try the patch out, but it most likely won't work
[15:55] <micahg> geser: it builds fine
[15:55] <geser> I'm surprised
[15:55] <geser> and LIBS would be a better place to add additional libraries instead of LDFLAGS
[15:56]  * Bachstelze nods
[15:56] <Bachstelze> -l* flags belong in LIBS, not LDFLAGS
[15:56] <micahg> ah, ok
[15:57] <Bachstelze> and yes, this is very ugly
[15:57] <Bachstelze> normally you would modify configure so that it puts the libs in the variables passed to MAkefile.in
[15:58] <geser> and another small issue: if the package needs to link with -lX11 -lXext -ldl the matching -dev packages should be listed in Build-Depends (for X11 and Xext)
[15:58] <micahg> could one of you comment on the patch then explaining why another way is better?
[15:59] <micahg> geser: that's another good point
[16:02] <micahg> ok, nm, I'll aggregate the comments here, thanks guys
[16:47] <paissad> hello, i see there are many tools to maintain a personal repository for .deb packages, (ftp-archive, apt-move, dpkg-scanpackages, mini-dinstall) ... what do you advice me ?
[16:49] <Nafallo> ppa on launchpad :-)
[16:49] <paissad> Nafallo, i do use it aleady
[16:49] <paissad> Nafallo, i ask this question for testing purpose
[16:50] <Nafallo> fair enough. I'd just set up a testing ppa though... *shrugs*
[16:50] <Nafallo> sorry for not being helpful.
[16:53] <crouk> Hi all
[16:53] <crouk> im new here
[16:54] <crouk> could someone help me with some question about MOTUs??
[16:54] <Nafallo> !ask | crouk
[16:55] <crouk> nice thanks! :)
[16:55] <Nafallo> ;-)
[16:55] <crouk> just getting involved on PyGtk and RubyGtk development
[16:56] <crouk> I just finish a new .deb package
[16:56] <crouk> and i don't know how to upload in the universe repository or just someone who do it for me
[16:57] <crouk> If the package is ok, sure...
[16:57] <Bachstelze> crouk: how "new" are we talking?
[16:58] <crouk> well, is 4 month old
[16:58] <crouk> is a MP3 tagger
[16:58] <crouk> do it with Ruby-gnome2 +glade
[16:59] <crouk> i do it a *.deb and I use it only in my comuter
[17:00] <crouk> I checked the MOTUs web and I don't know is this kind of contribution should we checked by another MOTU
[17:00] <crouk> or i can just register and contribute with them
[17:00] <Bachstelze> crouk: if it's a really new package, as opposed to a newer verison of an existing package, the best way is to submit it to Debian
[17:01] <Bachstelze> and then let it sync in Ubuntu automagically
[17:02] <crouk> OK. And how do I submit it to Debian?
[17:04] <Bachstelze> http://www.debian.org/doc/maint-guide/
[17:13] <crouk> nice :)
[17:13] <crouk> im reading the dupload doc now
[17:13] <crouk> so just upload the package with dupload and the Debian community will check it?
[17:14] <Bachstelze> no
[17:14] <Bachstelze> you can't use dupload because you are not a DD
[17:15] <Bachstelze> so you need to get a sponsor for your package
[17:16] <Bachstelze> this explains it: http://wiki.debian.org/DebianMentorsFaq
[17:30] <Bachstelze> hmm, wouldn't it be better to just create ubuntu1 revisions for all the packages that FTBFS with LD_ERROR than flooding Debian with patches that are mostly not relevant to them?
[17:31] <Bachstelze> I have the feeling that most of them won't be applied, so we'll find ourselves with one week before FF and a lot of patches to apply
[17:32] <azeem_> what's the reason for that LD_ERROR?
[17:32] <Bachstelze> azeem_: the new toolchain in Natty is much less tolerant of bad practice
[17:32] <Bachstelze> generally the packages put -l* flags in LDFLAGS instead of LIBS
[17:32] <azeem_> won't Debian have that toolchain at some point as well?
[17:33] <micahg> Bachstelze: wheezy will probably be similar, so they should be sent to Debian but with wishlist prioirty ATM
[17:54] <crouk> Bachstelze: thanks. Im reading now about to get sponsored
[18:31] <tumbleweed> bdrung: test_update_maintainer: You should probably unpatch os.path.isfile (ubuntutools.update_maintainer.os.path is os.path). I also see some trailing whitespace.
[19:05] <ebroder> ari-tczew: Oh, sorry - missed that you were looking at bug #694504
[19:06] <ebroder> I'll reset the status back to where you had it
[19:06] <ari-tczew> ebroder: what's the sense if you acked it?
[19:07] <ari-tczew> please learn to set in progress and assign to you if you're looking
[19:07] <micahg> ari-tczew: please unsubscribe -sponsors if you take a bug ;)
[19:07] <ari-tczew> micahg: this is the second thing
[19:07] <ebroder> micahg: I'm pretty sure this was my fault - I think I was looking at it before ari-tczew was
[19:08] <ebroder> Because it was unassigned when I pulled it up
[19:08] <micahg> I set to in progress, assign to me, and unsubscribe sponsors
[19:08] <ebroder> ari-tczew: Sorry. I sometimes forget when I'm looking at tickets that I think will be fast
[19:11] <ari-tczew> ebroder: officiousness is worse than fascism
[19:11] <ari-tczew> just anecdote
[19:26] <ari-tczew> ebroder: btw. if you are bored, I can find activity for you
[19:26] <DktrKranz> ari-tczew: wrt your gnome-user-share mail, I just replied to it
[19:27] <ari-tczew> DktrKranz: yes I know. unfortunately my pbuilder doesn't know about it :(
[19:28] <ari-tczew> (now I know)
[19:28] <DktrKranz> I think pbuilder ignores it
[19:33] <ari-tczew> perhaps
[19:34] <sebner> ari-tczew: I'm really surprised to see a polish guy saying that officiousness is worse than fascism
[19:34] <ari-tczew> sebner: why?
[19:35] <ari-tczew> this is quote is very popular in Poland
[19:35] <sebner> this surprises me even more
[19:35] <sebner> if you think about your past ..
[19:35] <ari-tczew> sebner: have you got problem with Poland?
[19:36] <sebner> ari-tczew: not really, just wondering if you forgot what happened 70 years ago
[19:38] <ari-tczew> sebner: hmm. I'm really interested what do you mean. maybe in your country is another history.
[19:39] <sebner> ari-tczew: not really, I'm from Austria ;)
[19:39] <sebner> ari-tczew: officiousness was a result of the fascism at that time imho
[19:39] <sebner> but we are quite OT
[19:41] <ari-tczew> aha
[19:45] <Bachstelze> # wc -l debian/patches/01-wsdl-stubs.patch
[19:45] <Bachstelze> 339162 debian/patches/01-wsdl-stubs.patch
[19:45] <Bachstelze> wow
[19:45] <Bachstelze> that's a big patch
[20:12]  * kklimonda doesn't know any Polish quotes about officiousness and fascism, and if there are any he doesn't agree with them.
[20:50] <ari-tczew> micahg: I'd like to not close bugs by you if fixed is not yet available. I mean bug 694118
[20:50] <micahg> ari-tczew: I closed the maverick task since it was invalid
[20:50] <ari-tczew> micahg: it confuses new users
[20:51] <ari-tczew> which clementine has got
[20:51] <micahg> ari-tczew: yes, but that task is for the maverick archive, not backports
[20:51] <ari-tczew> micahg: omg please open your eyes and see that there is no only policies and procedures
[20:52] <ari-tczew> micahg: what about launchpad bug janitor?
[20:52] <ari-tczew> doesn't close this bug after backport?
[20:52] <micahg> ari-tczew: no
[20:52] <ari-tczew> micahg: are you sure?
[20:52] <micahg> ari-tczew: I think the new helper might close backport bugs, but a bug task is only for an SRU, not a backport
[20:54] <ari-tczew> micahg: I'm out of words to describe this stiffness and bureaucracy
[20:55] <micahg> ari-tczew: it's a different workflow for SRU bugs and backports
[20:55] <ari-tczew> micahg: say it to newbies
[20:55] <ari-tczew> I know that you're master and for you everything is clear, but not for everyone
[20:55] <ari-tczew> I don't want scary new users
[20:56] <ari-tczew> and you don't help in this case
[20:56] <ari-tczew> I want to tell gtfo
[20:56] <micahg> ari-tczew: you can file a bug against launchpad to have the release tasks target different pockets if you like
[20:56] <micahg> ari-tczew: the way to do that is with a note in the description, not using a release task
[20:57] <tumbleweed> ari-tczew: I think the best thing to do in these cases is to close the task with a clear comment saying "backport tracked in LP: #foo, we don't use tasks to track backports"
[20:57] <ari-tczew> tumbleweed: tell this one to micahg
[20:57] <tumbleweed> micahg is presumably listening :P
[20:57]  * Bachstelze cries
[20:57] <ari-tczew> tumbleweed: reading
[20:57] <micahg> ari-tczew: I closed it with a comment about adding an appropriate backports task/bug
[20:58] <Bachstelze> spent all afternoon fixing linking errors in eucalyptus
[20:58] <Bachstelze> and now there's also some java errors that make the build fail
[20:58] <ari-tczew> Bachstelze: unfortunately, life is brutal
[20:59] <ari-tczew> micahg: you could include also new tracking bug number
[20:59] <ari-tczew> flow of information is very important
[21:00]  * ari-tczew doesn't know how that master couldn't consider about it
[21:00] <Bachstelze> !pastebin
[21:00] <Bachstelze> !pastebinit
[21:01] <micahg> ari-tczew: sorry, I didn't connect the two, I could've given bug #
[21:01] <ari-tczew> micahg: bravo!!!1111!
[21:01] <micahg> !msgthebot | Bachstelze
[21:01] <micahg> ari-tczew: would you like me to do that now?
[21:02] <ari-tczew> micahg: pleased, yes
[21:04] <micahg> ari-tczew: done
[21:08] <ari-tczew> micahg: thanks, now you can send delation to CC
[21:08] <micahg> ari-tczew: ?
[21:09] <ari-tczew> micahg: Questionable behavior from an Ubuntu member
[21:09] <ari-tczew> hehehe
[22:04] <akoskm> hi
[22:09] <akoskm> If I copy my *.so files to the /usr/lib/jni and then run the ldconfig in that directory, and after adding a configuration file to /etc/ld.so.conf.d/, specifying the path to /usr/lib/jni, If I start a java application the jvm should include the /usr/lib/jni path to not just the /usr/lib, isn't?
[22:11] <Bachstelze> akoskm: you should run ldconfig /after/ adding a file in /etc/ld.so.conf.d/
[22:12] <akoskm> Bachstelze, oh. that would be all? and doing by this way It will include the /usr/lib/jni too?
[22:13] <Bachstelze> not sure about Java, but that's how it would work in C
[22:13] <akoskm> okay, I'll try this out. thank you.
[22:13] <ebroder> akoskm: It seems a little weird to me that you'd have to change the linker configuration to enable Java's plugin system
[22:15] <akoskm> ebroder, why? I have no experience around packaging, if there any other ways to include the native libraries installed by my package let me know.
[22:16] <ebroder> akoskm: I don't know. But I would expect that you're just using the wrong directory or something
[22:16] <ebroder> I don't really know anything about Java. But have you looked at the Debian Java policy to see if it talks at all about JNI?
[22:17] <akoskm> yes
[22:18] <ebroder> akoskm: Looking for a random package that uses JNI, it looks like libswt3.2-gtk-jni just drops files in /usr/lib/jni
[22:18]  * ebroder shrugs. I probably don't know what I'm talking about
[23:34] <bdrung> tumbleweed: fixed. thanks.
[23:34] <bdrung> tumbleweed: there was only one trailing whitespace line, correct?
[23:40] <tumbleweed> yeah, that's all I saw
[23:40] <tumbleweed> bdrung: I posted a pyflakes tester
[23:40] <bdrung> tumbleweed: thanks for your pylint tester
[23:40] <bdrung> tumbleweed: pyflakes?
[23:40] <tumbleweed> err pylint
[23:41] <bdrung> tumbleweed: can you remove the items that are default values from the pylint config file?
[23:41] <tumbleweed> I was just saying I was alcoholically impaired in another channel, let me repeat that here :)
[23:41] <tumbleweed> probably, I should actually investigate that
[23:41] <bdrung> tumbleweed: and maybe it's better to disable unwanted test than enable wanted ones.
[23:42] <bdrung> tumbleweed: besides that it looks good
[23:42] <tumbleweed> that's just the config file I wrote, I didn't disable any tests
[23:42] <tumbleweed> s/I/it/
[23:44] <tumbleweed> bdrung: err "del ubuntutools.control.os.path.isfile" is that right?
[23:44] <tumbleweed> shouldn't be a save that value and restore it
[23:44] <bdrung> tumbleweed: replacing pylint.conf with an empty files thrown more errors
[23:44] <ebroder> tumbleweed, bdrung: Have you guys looked at python-mox? It's a better way for replacing built-in functions like that
[23:44] <ebroder> (I haven't actually looked at the tests yet, but I assume that's what you're doing)
[23:44] <bdrung> tumbleweed: "del ubuntutools.control.os.path.isfile" is what i learned from you
[23:45] <bdrung> tumbleweed: why should i save the function link?
[23:45] <tumbleweed> bdrung: aah, I added open to the module, I didn't replace teh open builtin
[23:46] <tumbleweed> ebroder: yeah, I wasn't doing anything *that* fancy, so I didn't look for libraries to help
[23:46] <bdrung> ebroder: it's the first time i hear about python-mox. link to doc?
[23:46] <ebroder> bdrung: http://code.google.com/p/pymox/wiki/MoxRecipes
[23:46] <ebroder> bdrung: Look at the "Mock a module-level function in a different module" example, for instance - that's the idiom I've used most frequently
[23:48] <bdrung> ebroder: merge proposals are welcome ;)
[23:49] <ebroder> bdrung: Afraid I don't have time for that at the moment; just wanted to make sure you guys were aware of Mox before you started duplicating what it does
[23:50] <bdrung> ebroder: i will consider using it the next time i work on a python test
[23:50]  * bdrung is setting a bookmark
[23:52] <ebroder> bdrung: Oh, and on the subject of testing tools, there's also https://github.com/mockfs/mockfs, which isn't packaged and which I've never used, but is probably also useful for faking out filesystem-based tests
[23:52] <ebroder> (docs at http://mockfs.github.com/)
[23:53] <tumbleweed> nice
[23:53] <ebroder> Although it looks like it only stubs out functions in os and os.path instead of, say, open, which makes it less useful
[23:53] <bdrung> ebroder: do you have a real world example for mox?
[23:53] <tumbleweed> oh, that's a bit less useful, yes
[23:54] <tumbleweed> it has an open-like function you could patch in, though
[23:57] <bdrung> ebroder: how to use StubOutWithMock on "open"?
[23:57] <ebroder> bdrung: You should be able to do StubOutWithMock(__builtins__, 'open'), I think
[23:58] <ebroder> http://pastebin.com/1DJZDxbs
[23:59] <bdrung> ebroder: self._mox.StubOutWithMock(__builtins__, "open") fails: AttributeError: 'dict' object has no attribute 'open'


[08:46] <lordievader> Good morning
[11:49] <SynfulAck> whats up with following the ansible install docs for an ubuntu 2004 server install? https://paste.ubuntu.com/p/wxMdj9sWdn/
[11:49] <SynfulAck> get a warning about a release file.
[11:50] <quadrathoch2> SynfulAck because there is no focal release yet
[11:51] <SynfulAck> well damn.
[14:56] <hendry> Hi, I need to be able to deploy to a bunch of the same model of Thinkpad Ubuntu.
[14:56] <hendry> I.e. I'm looking for a unattended netinstall, machine boots, gets its SSD partitioned, and Ubuntu copied in
[14:56] <hendry> How do I realise this please?
[15:06] <oerheks> !preseed
[15:06] <oerheks> look into preseed setup, hendry
[15:06] <oerheks> https://help.ubuntu.com/lts/installation-guide/s390x/apb.html
[15:07] <hendry> looks complex
[15:08] <oerheks> hendry, yes, but basicly it is easy , look at this howto step-by-step
[15:08] <oerheks> https://www.pugetsystems.com/labs/hpc/Note-Auto-Install-Ubuntu-with-Custom-Preseed-ISO-1654/
[15:08] <oerheks> for 18.04*
[15:10] <sdeziel> https://help.ubuntu.com/lts/installation-guide/amd64/apb.html is probably a better link for Thinkpads ;)
[15:11] <sdeziel> unless they are shipping laptops with s390x
[15:11] <oerheks> oops correct
[15:24] <icey> I definitely had to read that twice, I got excited for a moment for laptop scale s390x :-P
[15:48] <hendry> thanks guys


[06:51] <cpaelzer> hmm - is it a recent change that ppas are no more served from launchpad.net but from ppa.launchpadcontent.net ?
[06:51] <cpaelzer> Seems to have broken some of my automated tests, so I wonder about the timing and backgrounds if anyone knows more about it
[06:54] <cpaelzer> both servers seem to be up still, wget from both serves the same, so maybe only apt or add-apt-repository changed to use the new URL by default now ...
[07:10] <vorlon> cpaelzer: yes, in the past month; I know the Launchpad team included it in their internal weekly report, and it also required some changes to IIRC the core snap builds which I saw float by as MPs
[07:13] <cpaelzer> thanks vorlon
[07:13] <cpaelzer> thant confirms it isn't just me and my tests were quickly adapted and are fixed now
[10:50] <schopin> athos: I'm doing the python-debian merge, and have forwarded-ported your zstd patches. Given the comments on the Salsa MR, I figured you might be interested in these, since they keep the external tool approach :)
[10:50] <schopin> athos: https://salsa.debian.org/schopin/python-debian/-/tree/external-zstd
[11:17] <cjwatson> cpaelzer: Out of interest, what did it break?  https://bugs.launchpad.net/launchpad/+bug/1473091 has the background
[11:18] <cjwatson> cpaelzer: and https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1959015 for the add-apt-repository change
[11:31] <cpaelzer> thanks for the background cjwatson
[11:32] <cpaelzer> cjwatson: it did break tests that did use add-apt-repository - that started to fail since the URls were not in the no_proxy env and then got some ssl handshake issues
[11:33] <cpaelzer> it had a few different symptoms in different places, but adding launchpadcontent.net + api.launchpad.net to no_proxy resolved it all
[11:35] <cjwatson> cpaelzer: right, fair enough
[11:35] <cjwatson> slightly bumpy but it should be better in the long run
[11:35] <cpaelzer> since it wasn't change at jammy release day it should be fine after a short bumpy time
[11:36] <cpaelzer> I was told that this was in the launchpad weekly update (I have to admit I do not read that), maybe it would be time to announce that change a bit more
[11:36] <cpaelzer> to make it easier for others that might e.g. like me need to adapt proxy config
[11:37] <cpaelzer> "announce -> fix" is alway nicer than "fail -> debug - arrrrr -> fix" :-)
[12:04] <athos> schopin: thanks! still haven't figured out the merge myself :) => current dealing with how to handle large files
[12:05] <schopin> athos: fwiw I keep amending the linked branch because the CI seems particularly pedantic.
[16:28] <rbasak> utkarsh2102: hi! Did I hear correctly that you were going to look at the ruby-mysql2 dep8 holdup on mysql-8.0?
[16:29] <rbasak> I'm concerned to get the dep8 rdeps fixed for mysql-8.0. I'm not sure what might be caused by the OpenSSL 3.0 transition, what might be caused by a new upstream release, and now we have maybe some issues with language connectors that might be being affected by potential changes upstream, etc. So I don't have much confidence that there isn't a more serious blocker hiding somewhere that we don't know
[16:30] <rbasak> about yet.
[16:36] <utkarsh2102> rbasak: hey, yes, I'll take a look. I'll sync up with you or lenavoytek before diving into it.
[16:36] <rbasak> Thanks!
[16:36] <lena> thanks!
[16:47] <bluca> juliank: it seems some jobs on https://autopkgtest.ubuntu.com/running#pkg-systemd-upstream are running multiple times
[16:48] <bluca> I was watching the amd64 job for PR id 22458 and it completed successfully, went back to queued, and started over
[16:48] <bluca> there were no pushes on the PR
[16:48] <juliank> bluca: it might have failed
[16:48] <bluca> it ran for many hours and I caught glimpses from the log snippet
[16:48] <juliank> bluca: was there a push somehow that it passed?
[16:48] <bluca> it completed at least until the second to last job
[16:49] <bluca> /job/autopkgtest suite/
[16:49] <juliank> so it might have rebooted and failed to come up again
[16:49] <bluca> no push on the PR
[16:49] <bluca> https://github.com/systemd/systemd/pull/22458
[16:50] <juliank> bluca: this is failing
[16:51] <juliank> bluca: last run failed 35 mins ago
[16:52] <juliank> um
[16:52] <juliank> well timing is wrong
[16:52] <bluca> is the failed log accessible?
[16:52] <bluca> also any reason it's just rerunning instead of reporting the failure?
[16:52] <juliank> no
[16:52] <juliank> if the machine fails to come back up again after a reboot it's a testbed failure that will be retried 3 times or so
[16:53] <juliank> you'll have to wait until it failed often enough or passed
[16:53] <juliank> there is no useful log
[16:54] <juliank> It's also not just systemd upstream jobs, machines just don't always come back up in general
[16:54] <juliank> or lose network connectivity
[16:54] <juliank> about 25% of the tests on amd64 are such abnormal failures
[16:54] <bluca> uhm but why is the machine rebooting before all the autopkgtest suites are done?
[16:55] <juliank> because it's rebooting between tests
[16:55] <bluca> is that expected?
[16:55] <juliank> yes
[16:55] <juliank> or like between testbed setup and tests
[16:55] <jawn-smith> vorlon: I know you love removing packages
[16:55] <bluca> ok, got it, thanks
[16:55] <jawn-smith> LP: #1960433
[16:55] <juliank> I have no idea how to debug this further
[16:55]  * vorlon oils the chainsaw
[16:56] <juliank> I'd have to patch autopkgtest to keep one such failing machine around I suppose
[16:56] <juliank> I've tried to reproduce the issue manually multiple times, but those always work
[16:57] <juliank> maybe I should create a vm and do a reboot loop
[16:59] <vorlon> jawn-smith: first I need to know if this is parsed as aegi-sub or aegis-u-b
[17:01] <vorlon> jawn-smith: for reference, the existence of Debian bug #997098 is sufficient for me, no need to file a separate bug in Ubuntu if there's already a release-critical Debian bug for the issue
[17:08] <juliank> vorlon: failure count today of amd64 hosts: https://paste.ubuntu.com/p/F9D7xpvnqJ/
[17:08] <juliank> I'd like to get an instance on elektra really
[17:09] <juliank> IS did a soft restart of all OVS but it did not help
[17:14] <vorlon> :/
[17:19] <juliank> vorlon: OK I see in the failing logs that systemd is starting a job called "/usr/bin/sh -c sleep 3; reboot"
[17:19] <juliank> vorlon: I wonder where that is from
[17:19] <juliank> vorlon: I think if the machine reboots itself vs the outside, autopkgtest gets confused as it still expects it to be up
[17:22] <juliank> Because the machines take ages to boot due to load right now
[17:24] <juliank> Startup finished in 7.265s (kernel) + 15.902s (userspace) = 23.167s
[17:27] <jawn-smith> vorlon: it's a subtitles package so I'm going with aegi-sub. Thanks for the tip about the Debian bug
[17:35] <juliank> vorlon: So I added -o ConnectionAttempts=20 to the ssh command autopkgtest auxverb uses which will make it try to connect 20 times with 1s timeouts, maybe that helps
[17:36] <juliank> I guess I should hack that into existing running processes
[18:07] <juliank> we now have debugging enabled for half the jobs
[18:36] <juliank> vorlon: I locally hacked in NOVA_REBOOT=1 in ssh-setup/nova and will see if that helps. It seemingly helped a long long time ago in bos01
[18:36] <juliank> (pitti added --nova-reboot to the worker.conf; but we don't really have the luxury to reload workers right now)
[18:41] <bdmurray> I'm trying the new aiocoap w/ python3.10 defaults
[18:44] <bdmurray> hrm, I might have jumped the gun there
[23:46] <jawn-smith> seb128: can you have a look at LP: #1960458 when you get a chance? Your name is on the patch that is causing the issue
[23:46] <jawn-smith> or, at least the changelog entry for that patch


[15:25] <Pendulum> ooh... this looks interesting http://www.bbc.co.uk/ouch/features/fix_the_web.shtml
[15:57] <UndiFineD> thanks Pendulum
[18:36] <Pendulum> TheMuso: out of curiosity (and based on the e-mail that went out to #ubuntu-devel between google docs or etherpad, which is more likely to be accessible to you?)
[20:16] <TheMuso> Pendulum: Between google docs and etherpad, I think etherpad.
[20:17] <Pendulum> TheMuso: I don't know if you've seen the discussion going on on the ubuntu-devel mailing list? I figured it didn't hurt to mention what works best from an accessibility standpoint
[20:35] <TheMuso> Pendulum: What discussion? Just geting to emaoil this morning.
[20:39] <TheMuso> Oh right, something better than gobby.
[22:26] <Nafai> so, as I've become more aware of my reduced vision, I really have a hard time with low contrast things
[22:26] <Nafai> Does anyone have a color scheme for gnome-terminal that provides decent contrast (I've been using the standard white on black)?
[22:28] <charlie-tca> I use a black text on very light yellow for that very reason. The background yellow I use is #FFFFF0 or Red 255, Green 255, Blue 240
[22:29] <Nafai> I'll give that a try, thanks
[22:29] <charlie-tca> I have a very hard time reading the white text on black and most other combinations with a dark background


[04:21] <ralf> hi all
[19:05] <gregk> hello all - how do I set my xubuntu machine to follow the ntp clock I'm running on my router?  I have to add a package of some sort?
[19:16] <gregk> *ntp SERVER I'm running on my router?
[19:28] <gregk> looks like I just have to uncomment a line or 2 in the conf file
[19:28] <gregk> and add my server addy
[21:03] <xu-help82w> hey my has starting to shut off when i watch videos
[21:03] <xu-help82w> screen
[21:11] <xu-help82w> my phone screen is turning off also and i logg off would be approciated for help its the secound time i ask


[21:42] <cprofitt> hello folks
[21:43] <cprofitt> I corrected your re-approval date to 2013-6-27
[21:43] <maco> hi
[21:44] <maco> thanks
[21:44] <cprofitt> no problem
[22:43] <ChinnoDog> omg, life


[01:09] <gsker> @search The Switch O'Leary
[01:10] <sarnold> ?
[06:02] <lordievader> Good morning
[11:06] <punkgeek> I want to run wget to send a signal after initramfs configure network. How can I do it?
[11:12] <lordievader> Unless required the network is only configured at a later stage, not in the initramfs.
[11:12] <lordievader> Not really sure why you want to download something, but you can make a systemd unit which targets the network-online.target.
[11:16] <punkgeek>  I've encrypted my whole disk with LUKS and I've installed Busybox with the network configuration. So when VM has been rebooted, I can connect to Busybox with SSH to enter my LUKS password.  I want to run the wget command automatically after the initramfs network is configured, to send a signal from VM to enter the LUKS password.
[12:27] <TJ-> punkgeek: why not delply mandos instead?
[12:27] <TJ-> or even, deploy
[13:39] <lordievader> punkgeek: In `/etc/initramfs-tools/scripts` and `/usr/share/initramfs-tools/scripts` are a bunch of scripts which are called at certain points. I guess you can figure out (with the documentation) at which point there should be a network and inject your script there.
[15:05] <punkgeek> TJ-: I can't use this method in my case.
[15:06] <punkgeek> lordievader: I've tried both directories but it doesn't works. and even there in't any script on the /etc/initramfs-tools/scripts or hooks
[15:07] <TJ-> punkgeek: are you using dropbear-initramfs ? if so put your looks in just after dropbear's
[15:08] <TJ-> punkgeek: hooks are used at {mk,update}initramfs time, scripts are copied into the initrd.img
[15:09] <TJ-> for example, dropbear-initramfs installs, amongst others:
[15:09] <TJ-> dropbear-initramfs: /usr/share/initramfs-tools/scripts/init-bottom/dropbear
[15:09] <TJ-> dropbear-initramfs: /usr/share/initramfs-tools/scripts/init-premount/dropbear
[15:16] <lordievader> punkgeek: did you verify with `lsinitramfs` if they made it into an updated intramfs?
[15:29] <punkgeek> I'm not sure it uses dropbrea-initramfs or not, but I have installed it with busybox.
[15:29] <punkgeek> I've entered the command at the end of the .../init-premount/dropbear file and then I entered update-initramfs -u, But it didn't work
[15:30] <TJ-> punkgeek: you've put wget into the initrd as well?
[15:31] <lordievader> punkgeek: This shows about what you try to do, but then with curl: https://serverfault.com/questions/152959/configure-initramfs-tools-to-add-curl-to-the-initramfs-and-run-curl-in-a-script
[15:31] <punkgeek> TJ-: Could you explain more?
[15:32] <punkgeek> I saw this documents, Actually it just install curl on the busybox. because it doesn't have curl
[15:32] <TJ-> punkgeek: if you want a binary, or other file, installed into the initrd you have to create a hook script that includes the hook-functions script and calls copy_file(path/to/file)
[15:33] <TJ-> punkgeek: OK, so you're relying on the busybox already installed in the initrd as a busybox applet?
[15:33] <punkgeek> also someone asked how to run automatically a curl command and no one response on the mentioned topic
[15:34] <TJ-> the version of busybox installed is a cut-down, from /usr/lib/initramfs-tools/bin/busybox (package busybox-initramfs)
[15:34] <TJ-> punkgeek: might be worth checking the built-in wget there has the options you're relying on, with "/usr/lib/initramfs-tools/bin/busybox wget -h"
[15:36] <punkgeek> it works "/usr/lib/initramfs-tools/bin/busybox wget -h"
[15:36] <TJ-> punkgeek: if it isn't working and you have a console on the system, then edit the kernel command-line in the boot config to have "break=premount" so it drops to the shell and you can manually test the command and explore
[15:37] <punkgeek> I'm not sure it is a good idea to do it by busybox, because maybe before the ssh login, busybox wouldn't start
[15:39] <TJ-> busybox is running the /init script!
[15:39] <punkgeek> but in /etc/initramfs-tools/initramfs.conf seems init start the busybox
[15:40] <punkgeek> Howevre, I can change it to run automatically
[15:42] <TJ-> we don't use klibc tooling
[15:44] <TJ-> oh actually, it's /usr/bin/dash now !
[15:46] <TJ-> hahaha no it isn't it's busybox. I accidentally checked /bin/sh not bin/sh in the extracted initrd.img, oops
[15:51] <punkgeek> So is there any suggestion to help me?
[15:54] <rbasak> punkgeek: have you tried a keyscript?
[15:54] <rbasak> For example I wrote https://github.com/basak/netkeyscript a long time ago.
[15:54] <rbasak> You could use that as a model to get the behaviour you want with a different script I think.
[15:59] <punkgeek> It's good, But I can't use this method in my case.
[15:59] <rbasak> No, but you can implement whatever method you want in a keyscript
[15:59] <rbasak> Then update-initramfs will insert it into the initramfs automatically I think
[16:11] <punkgeek> my literacy level can't understand that script :D
[19:04] <octav1a> Hello, I have two compute clusters with their own disk shares in two different geographic locations. For ease-of-use I've been prompted to consider adding some kind of file share between them (over the internet). Something like an sshfs connection on each side. Does anyone have an idea of how to do this on a system level instead of each user managing their own? I'm guessing I would need to use root in order to properly serve all users...
[19:05] <sarnold> octav1a: that sounds a bit like openafs
[19:07] <bahamat> Hey all, I'm trying to bring up LXC instances with a custom network config. Using images:ubuntu/18.04/cloud, I can see that /var/lib/cloud/seed/nocloud-net/network-config does have the config I passed in, but /etc/netplan is empty and cloud-init never ran.
[19:08] <octav1a> sarnold: to be clear, when I hear distributed file system I think of something like gluster. In this case I want both the file systems to be completely independent, but just corss mounted .
[19:08] <octav1a> cross*
[19:08] <octav1a> (ex on system1 there will be /data (local) and /data-system2 (remote)  ; and on system2 there will be /data and /data-system1
[19:08] <bahamat> If I run `cloud-init init` manually it does its thing, then running `netplan apply` brings up the proper network config. So my question is why isn't cloud-init running automatically like it's supposed to?
[19:22] <rbasak> ^ I answered in #ubuntu
[19:22] <rbasak> Solution: use ubuntu:bionic, not images:
[19:23] <rbasak> For support for images:, try #lxcontainers
[19:23] <leftyfb> rbasak: it's called #lxc now
[19:23] <rbasak> Thanks
[20:03] <punkgeek> Isn't there any way to run a command in busybox startup automatically?


[00:35] <slangasek> bdmurray: 1401390> as a regression-update bug, yes, I think that's reasonable provided that it's passed verification this time
[09:22] <Riddell> stgraber: can you turn off cron for images?
[09:33] <xnox> darn, can't slip a new ubiquity in.
[09:46] <Mirv> preNEW binary check for indicator-network-tools in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+packages would be needed (packaging changes https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-network_0.5.1+15.04.20141216-0ubuntu1.diff)
[10:46] <Riddell> utlemming: is cloud in alpha 1? https://wiki.ubuntu.com/VividVermat/Alpha1
[10:46] <Riddell> knome elfy: is xubuntu in alpha 1? https://wiki.ubuntu.com/VividVermat/Alpha1
[10:47] <Laney> Vervet
[10:47] <doko> cjwatson, pitti: looka like we need some coordinated effort to get isl/gcc/ghc into -release
[10:48] <Riddell> ahem, https://wiki.ubuntu.com/VividVervet/Alpha1
[11:36] <Riddell> alpha 1 freeze in place for kubuntu, ubuntu gnome, ubuntu kylin
[11:37] <cjwatson> doko: isn't the problem just that gcc-4.9 is stuck at the excuses stage due to an autopkgtest regression?  I don't think ghc is actually directly involved, it's just that that stack all shows up in update_output because cpp is uninstallable with the current autohinted set
[11:38] <cjwatson> doko: can't do much with the alpha 1 freeze block though ...
[11:39] <cjwatson> doko: that autopkgtest failure looks transient as stated, retried, but it's been failing for a while
[12:25] <cjwatson> doko: here's the output if gcc-4.9 were included: http://paste.ubuntu.com/9539880/
[12:26] <cjwatson> doko: so I think you just need to rebuild gnat-mingw-w64
[12:30] <Laney> hint-tester, nice
[13:07] <elfy> Riddell: no - we are likely to start with a2 this time earliest
[13:07] <elfy> thanks
[13:07] <Riddell> gotcha
[13:47] <doko> cjwatson: right, already done. didn't see that it was built from a different source
[14:10] <stgraber> Riddell: so turn off for kubuntu, gnome and kylin?
[14:10] <Riddell> stgraber: yep
[14:11] <stgraber> doing
[14:12] <stgraber> Riddell: done
[14:12]  * stgraber looks at the tracker now
[14:19] <stgraber> Riddell: alright, the tracker should be good to go too
[14:19] <Riddell> stgraber: is that not something I (or whoever is on duty) can do?
[14:20] <stgraber> usually, yes but the first milestone is special as I need to copy some data over from the previous series in the DB
[14:20] <stgraber> (which I arguably should be done at series opening time, but well, that never quite happens)
[14:32] <cjwatson> Laney: Yeah, finally decided to try it
[15:10] <rcj> stgraber, cloud is in for alpha-1.  Odd_Bloke will be driving this time, with myself and utlemming as backup.
[15:11] <stgraber> Riddell: ^
[15:16] <Riddell> rcj: gotcha
[15:17] <rcj> Riddell, thanks.
[15:54] <knome> Riddell, no, xubuntu isn't in for alpha 1 if you're still wondering :) and our new project lead is ochosi, so you'll want to ping him in the future :)
[15:58] <Riddell> hi ochosi, congratulations on your promotion
[15:59] <Riddell> stgraber: can your turn off the kubuntu-plasma5 cron for good?
[16:00] <Riddell> real kubuntu is working nicely as plasma 5
[16:00] <stgraber> Riddell: sure
[16:00] <knome> Riddell, promotion... more work and more bureaucracy? yeah, congratulations ochosi ;]
[16:09] <Riddell> stgraber: how do we add builds to the vivid 1 milestone in iso qa?
[16:10] <stgraber> Riddell: if you want to rebuild anyway, just ask for a rebuild on the daily milestone and the build will get added to alpha 1 once it's done
[16:10] <stgraber> if you want to add an existing build, then it's a bit trickier :)
[16:10] <stgraber> (either need to manually add it through the UI using the exact same information as the existing one, or manually add the relation in the DB)
[16:11] <infinity> Less hassle to just rebuild all the dailies that are participating in A1 so they pop up on the milestone.
[16:12] <Riddell> groovy worked it out http://iso.qa.ubuntu.com/qatracker/milestones/328/builds
[17:11] <wxl> stgraber: lubuntu is in for alpha 1
[17:13] <stgraber> Riddell: ^ (I'll turn off cron, can you take care of the rest?)
[17:15] <Riddell> wxl: you're the lead?
[17:16] <Riddell> wxl: got a real name?#
[17:17] <wxl> Riddell: yep, Walter Lapchynski.
[17:17] <Riddell> wxl: ok let me know if you need anything added to iso tracker
[17:17] <stgraber> cron updated
[17:19] <stgraber> and enabled lubuntu in the vivid manifest
[17:19] <stgraber> Riddell: we have the IRC nicks of all the leads at: http://iso.qa.ubuntu.com/qatracker/series/47/manifest/full
[17:20] <wxl> i just disabled the ppcs as we're trying to stick with lts on those
[17:20] <stgraber> ok
[17:20] <Riddell> ah yes I always forget about that page
[17:25] <wxl> aw shoot what should the version string be? does it matter?
[17:26]  * Riddell freezes lubuntu packages from transitioning
[17:27] <wxl> ?
[17:27] <Riddell> wxl: 20141216 ?
[17:27] <wxl> really, that's what we use for milestone releases?
[17:27] <wxl> sorry i forget this every time :)
[17:28] <wxl> oh well
[17:28] <wxl> ic
[17:28] <wxl> so do i need to request a rebuild now?
[19:20] <arges> infinity: hey, i just did an 'sru-release utopic horizon', and ubuntu2 should have been copied to -updates, but alas it seems stuck in -proposed . Any ideas what I screwed up here?
[19:28] <arges> infinity: n/m
[19:47] <infinity> arges: Lack of patience?
[19:47] <arges> infinity: yea... the other ones were so quick.
[21:51] <arges> infinity: ok so I see https://launchpad.net/ubuntu/+source/horizon/1:2014.2.1-0ubuntu2, yet rmadison -a source horizon | grep trusty-updates shows : 1:2014.1.3-0ubuntu1 . Its been like this for a while, not sure why this particular package is hung up
[22:06] <arges> ok its all good
[22:06]  * arges lays off the caffiene