<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
00:01 <kaniini> i think we need a marketing team which handles that stuff
00:04 <jirutka> i think that one person would be enough for now :P
00:05 <kaniini> well it would be good option to spread the burden out
01:24 s33se_ joined
01:49 tmh1999 joined
01:50 leitao joined
03:21 tmh1999 joined
03:29 minimalism joined
04:20 tmh1999 joined
04:26 vakartel joined
04:39 BitL0G1c joined
05:31 terra joined
05:32 fabled joined
06:28 vakartel joined
06:49 t0mmy joined
07:27 stwa joined
07:31 terra joined
07:34 <xsteadfastx> clandmeter: one last question. why doest apk add snapcast-client trigger the pre install script? its only defined in the global install section. or is this section valid for all subpackages?
07:34 <clandmeter> does or doesnt?
07:35 <xsteadfastx> i mean it works. apk add snapcast-client triggers the pre install script just fine
07:35 <xsteadfastx> *does
07:35 <clandmeter> the install scripts name should match the pkgname
07:36 <clandmeter> then they are added to to correct pkg
07:36 <xsteadfastx> if they are defined in "install="
07:36 <xsteadfastx> ?
07:36 <clandmeter> yes
07:36 <xsteadfastx> ok ok
07:36 <xsteadfastx> that was complicated for me to understand. but now it works... the thing is... you did all the work ;-)
07:37 <clandmeter> $pkgname.pre-install $subpkgname.pre-install (iirc)
07:38 <clandmeter> well, you need to know how it works if you want to maintain it :)
07:38 <clandmeter> thats what we did now.
07:38 <xsteadfastx> true
07:38 tty` joined
07:38 <xsteadfastx> soon i will migrate my personal snapcast and mopidy setup to alpine... and i will be happy :)
07:39 <clandmeter> im waiting for rust to land in alpine
07:39 <clandmeter> then we can add spotify :)
07:42 <xsteadfastx> hahaha cool... maybe i should add a mopidy pkg again
07:44 <Shiz> clandmeter: spotify uses rust?
07:44 <clandmeter> check librespotify
07:45 <clandmeter> https://github.com/plietar/librespot
07:45 <clandmeter> Rust 1.15.0 or later is required to build librespot.
07:45 <Shiz> heh
07:45 <Shiz> there's always also despotify
07:45 <Shiz> ;P
07:45 <clandmeter> that works?
07:46 <clandmeter> its 8 years old
07:46 <Shiz> i dunno
07:46 <clandmeter> i think we need librespot, atleast thats what ive seen works.
07:48 <Shiz> :p
07:48 <Shiz> clandmeter: rust is in testing right now so
07:48 <Shiz> feel free to give it a shot
07:48 <clandmeter> does cargo work?
07:48 <Shiz> yes
07:49 <Shiz> the only issue is that we can't properly verify cargo deps yet
07:49 <Shiz> i wrote a hack for it but it's not very great
07:49 <Shiz> (involves # cargo fetch during fetch(), taring it up and checking that sum)
07:50 terra joined
07:51 t0mmy joined
07:54 royger joined
07:55 <xsteadfastx> any way to do a check() for python modules?
07:56 t0mmy joined
07:57 stwa joined
07:57 <clandmeter> not if it doesnt provide something itself.
07:57 <Shiz> the simplest way to do a check if just checking if the binary that belongs to the package runs with e.g. --version
07:57 <Shiz> if there is nothing else
07:57 <clandmeter> thats hard with a python module :)
07:58 <Shiz> there's also python setup.py test apparently
07:58 <Shiz> not sure how many packages support integration with that...
07:58 <clandmeter> yes, if they provide it then thats sane to use.
07:58 <clandmeter> you could write your own tests, but thats out of the scope of package maintaining imho.
07:59 <Shiz> yeah
08:02 <ncopa> morning
08:02 <ncopa> any volunteer for marketing team?
08:02 <ncopa> who can do the @alpinelinux twitter?
08:07 <Shiz> :P
08:07 <Shiz> morning
08:11 <xsteadfastx> first thought was a python -m modulename but that doesnt work if there is now __main__
08:14 consus joined
09:03 stwa joined
09:32 <_ikke_> xsteadfastx: python -i?
09:34 <xsteadfastx> mh i dont know about that one
09:34 <xsteadfastx> else just check for the location? but thats not really a test if the pkg is working
09:43 lmf_ joined
10:11 hiro joined
10:14 <ncopa> is "misery" here?
10:18 <^7heo> misery is everywhere in this world.
10:18 <* ^7heo> hides
10:23 <hiro> ncopa: i have some left if you want :)
10:36 <clandmeter> Shiz, any idea about this one? http://tpaste.us/DkOz
10:44 <Shiz> clandmeter: yeah sec
10:57 gromero joined
10:57 gromero joined
11:06 <Shiz> clandmeter: it happens when you try to create a dylib with static-crt
11:06 <Shiz> which is not correct
11:10 <jirutka> ncopa: I’m not a marketing person, but I think that I can handle @alpinelinux Twitter, if no one more competent show up :)
11:11 <ncopa> i'd prefer you spend you time on coding
11:11 <ncopa> :)
11:18 vakartel1 joined
11:22 czart joined
11:23 stwa_ joined
11:28 <jirutka> ncopa: okay :)
11:41 <ncopa> im looking at mseon build system
11:41 <ncopa> meson
11:41 <ncopa> looks pretty nice
11:41 <ncopa> however, it depends on python
11:42 <fabled> yeah, i kinda like meson idea too
11:42 <hiro> what do you guys think about the one from void?
11:42 <ncopa> would be nice to port meson to lua
11:42 <ncopa> or even C
11:42 <hiro> not sure meson is of that kind, but it reminds me anyway
11:43 <hiro> is it a make system?
11:43 <ncopa> hiro: void?
11:43 <ncopa> its a autoconf replacement
11:43 <ncopa> cmake/autoconf alternative
11:43 <hiro> oh!
11:43 <ncopa> generate ninja files
11:43 <hiro> sorry to intrude then, i hate those kinds of things! :P
11:43 <ncopa> ninja is a better make
11:44 <jirutka> what do you think about https://github.com/gittup/tup ?
11:44 <jirutka> I don’t know much about it, found it by accident
11:44 <hiro> too many people tried to make me use their make systems haha
11:44 <ncopa> dunno
11:45 <ncopa> but i really like ninja as backend
11:45 <ncopa> but ninja files needs to be generated
11:45 <ncopa> gnu make you dont really need to generate
11:45 <jirutka> hiro: well, I think that anything is better than autohells, make and cmake…
11:46 rdutra joined
11:46 <ncopa> you can use gnu make without generating them, but it gets quickly unreadable
11:46 <jirutka> speaking about Lua: https://github.com/sebnow/lake (but it’s very outdated and unmaintained)
11:46 <ncopa> and if you generate it, then better use ninja
11:46 <ncopa> i heard of lake yes
11:46 <ncopa> but not maintained
11:46 <hiro> i'm against generating it
11:46 <_ikke_> I'm currently using redo
11:46 <jirutka> eh, no, this is more up-to-date source: https://github.com/stevedonovan/Lake
11:47 <_ikke_> anyone heard of it?
11:47 <ncopa> but i like ninja :)
11:47 <ncopa> _ikke_: nope
11:47 <ncopa> ninja scales
11:47 <jirutka> beucase it includes real ninjas inside? :P
11:47 <hiro> a bad thing possibly
11:47 <hiro> scale is an excuse for useless complexity sometimes
11:47 <ncopa> you can build huge things like chromium with it
11:48 <ncopa> few other build systems can scale that
11:48 <hiro> yes, creating less chances for a more sane chrome alternative to ever come up
11:48 <consus> With make you can build Linux kernel
11:48 <hiro> i don't care if google gets problems compiling chrome or not!
11:48 <Shiz> @ncopa │ you can use gnu make without generating them, but it gets quickly unreadable
11:48 <jirutka> hiro: true when done wrong, that’s unfortunately most of the time :/
11:48 <Shiz> i object to this statement
11:48 <hiro> consus: goodd point, hahaha
11:49 <consus> That's what I call scalability
11:49 <hiro> jirutka: what is true?
11:49 <ncopa> i think thre are some project of using ninja for kernel
11:49 <consus> Though they do have their own configuration language
11:49 <jirutka> hiro: "scale is an excuse for useless complexity sometimes"
11:49 <ncopa> https://github.com/rabinv/kninja
11:50 <hiro> jirutka: ah, yes i agree
11:50 <clandmeter> Shiz, do you have an idea on how to fix that error?
11:50 <ncopa> kernel would be better built with ninja
11:50 <Shiz> clandmeter: i've talked about it in my post on rust-internals
11:50 <ncopa> i mean faster
11:50 <Shiz> :P
11:50 <Shiz> i think the best way is just to... ignore building the dylib
11:50 <Shiz> when target-feature=crt-static is set
11:50 <clandmeter> i have no experiance with rust or cargo
11:50 <hiro> ncopa: i don't need the kernel to build faster
11:51 <clandmeter> any hint would be appreciated :)
11:51 <consus> It would be nice to run a benchmark on a full build
11:51 <jirutka> clandmeter: what are you trying to solve?
11:51 <hiro> clandmeter: evacuate
11:51 <hiro> clandmeter: press the fire alarm, call in sick the rest of the month
11:51 <consus> On a webpage there is a comparison between make -j8 and ninja when nothing changes
11:51 <clandmeter> jirutka: http://tpaste.us/BeX4
11:51 <consus> Only 2 seconds gain
11:51 <ncopa> hiro: well, i need *everything* to build faster :)
11:52 <ncopa> specifically autoconf stuff
11:52 <hiro> clandmeter: it's better for the tax payer in the end than if you go total lunatix with rust
11:52 <Shiz> clandmeter: it'd need a cargo patch
11:52 <consus> Well autoconf repeatedly checks for the presence of <string.h>
11:52 <Shiz> not sure if i have time for it today
11:52 <consus> These people are insane
11:53 <jirutka> clandmeter: pkgs for software written in rust would be a bit more complicated b/c of dependencies; it’s on my priority list
11:53 <clandmeter> jirutka, it worked befroe with old rust
11:53 <clandmeter> not sure its because of rust/cargo or this project evolving.
11:54 <jirutka> clandmeter: try to add RUSTFLAGS="-C target-feature=-crt-static"
11:54 <jirutka> clandmeter: I’ll look at it later, have to go to lunch now
11:54 <Shiz> yeah that one makes it work
11:55 <jirutka> clandmeter: I’m gonna set dynamic linking for our rust as default, then this will not be needed
11:55 <clandmeter> btw, what are we planning to do with cargo files like git and registry?
11:55 <jirutka> clandmeter: I don’t know yet, have to do some research
11:56 fcolista joined
11:56 <jirutka> clandmeter: I’d like to get rid of need to clone registry repo and have just Cargo.lock and crate packages, but not sure if it’s currently possible
11:57 <clandmeter> think we should prevent it to polute $HOME, but using $srcdir takes too much time...
11:57 <jirutka> clandmeter: cause it’s insane to always have entire registry.io clone that is dozens of megabytes when all the needed information is already in Cargo.lock
11:58 <jirutka> clandmeter: ofc, we set CARGO_HOME to $srcdir, to not pollute $HOME
11:59 <Shiz> you can't use cargo.lock without the registry
11:59 <Shiz> sadly
11:59 <jirutka> btw we need to make rust-bootstrap pkg to cross-compile rustc from glibc to musl, to not rely on binaries from VoidLinux… ghc-bootstrap may be useful as example…
12:00 <jirutka> Shiz: I hope that cargo can be somehow *forced* to it… :)
12:00 <clandmeter> rust is slow...
12:02 <clandmeter> looks like its getting a bit further.
12:02 <Shiz> jirutka: negative
12:02 <Shiz> as far as i know
12:03 <clandmeter> Finished release [optimized] target(s) in 332.45 secs
12:03 <Shiz> yeah rustc is slow...
12:03 <clandmeter> \o/
12:03 <algitbot> \o/
12:04 <Shiz> jirutka: clandmeter: i may have found a nice approach
12:04 <Shiz> for the error you got, clandmeter
12:04 <clandmeter> ok
12:05 <clandmeter> in what way is it better then the current fix?
12:05 <Shiz> uhm
12:05 <Shiz> the current fix isn't really a fix
12:05 <Shiz> it's just a workaround
12:05 <Shiz> :P
12:05 <Shiz> it tells it to link everything dynamically
12:05 <clandmeter> it fixes my build :p
12:05 <Shiz> which is what we want to default to in the end
12:05 <Shiz> BUT
12:06 <Shiz> it doesn't change that static linking is somewhat broken atm
12:06 <Shiz> and i can fix that in the core compiler
12:06 <Shiz> i know exactly where to put it
12:06 <Shiz> :P
12:06 <clandmeter> you want me to compile it static?
12:07 <Shiz> no, just saying my fix fixes the fundamental issue
12:07 <Shiz> not just the symptoms you saw
12:08 <clandmeter> ah ok, so the result is the same/
12:08 <clandmeter> ?
12:12 <Shiz> yeah
12:13 <jirutka> Shiz: hm, I built rustc with dynamic as default and now almost all cargo tests pass…
12:13 <Shiz> jirutka: :)
12:13 <Shiz> because it doesn't tryo create dylibs on crt-static anymore
12:13 <Shiz> which was the root cause remember
12:14 <jirutka> not sure, there were more problems
12:14 <jirutka> btw we didn’t run ALL cargo tests before
12:14 volleyper joined
12:15 <jirutka> now we do, with --no-fail-fast
12:15 <Shiz> ah
12:15 <Shiz> got a log?
12:16 leitao joined
12:19 volleyper left
12:26 minimalism joined
12:31 <jirutka> Shiz: cargo built as dynamic with rustc building static as default: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/cargo/cargo-0.17.0-r1.log
12:32 <Shiz> right
12:32 <jirutka> Shiz: cargo built as dynamic wirth rustc building dynamic as default: https://hastebin.com/raw/ahehubijay
12:33 <clandmeter> rust/cargo is x86_64 only for now?
12:34 <jirutka> clandmeter: yes, for now
12:34 <jirutka> clandmeter: I hope that we can use abuild support for cross-compiling to compile it for other arches, but as i know there’s no documentation at all for it, so must fabled how it works
12:41 <Shiz> Error loading shared library libstd-08ebb426f9085302.so: No such file or directory (needed by target/debug/foo)
12:41 <Shiz> hmm
12:42 farosas joined
12:43 <Shiz> jirutka: 4 failures isnt bad
12:43 <Shiz> :P
12:44 <jirutka> yeah, and I’ve fixed one of them right now
12:44 <jirutka> just stupidity, he assets User-Agent header that contains version of libgit2…
12:44 <Shiz> jirutka: i don't think the http_auth one is our fault
12:44 <Shiz> ah
12:44 <jirutka> asserts
12:44 <Shiz> :D
13:06 <jirutka> Shiz: pushed updated testing/rust with dynamic linking as default and cargo with fixed test build-auth:http_auth_offered
13:06 <jirutka> Shiz: and now I must really go back to work, I have done almost nothing this week, can’t unbind myself from this :)
13:08 <Shiz> jirutka: i hope you put the dynlink-default in a separate patch
13:08 <Shiz> :P
13:08 <Shiz> good luck!
13:08 <jirutka> Shiz: hm, no, I put it into fix-linux_musl_base.patch
13:08 <Shiz> :(
13:08 <Shiz> that fucks up my internals post
13:08 <Shiz> :P
13:09 <jirutka> aha, sorry :(
13:09 <Shiz> since those three patches are supposed to be upstreamable
13:09 <jirutka> okay, I’ll change it
13:09 <Shiz> thanks :)
13:09 <Shiz> jirutka: uh, can i still ping you if you're working
13:09 <Shiz> i got an incoming patch for you once i'm done testing it
13:09 <jirutka> :)
13:10 <jirutka> yes, also please remind me to split the patch we’ve talked about
13:10 <jirutka> afk
13:10 <Shiz> \o
13:19 <jirutka> Shiz: fix-linux_musl_base.patch currently depends on static-pie.patch…
13:19 <Shiz> right
13:19 <Shiz> and? :P
13:20 <jirutka> just saying, if you aware of it
13:21 <jirutka> we have about four patches that modifies linux_musl_base :/
13:21 <Shiz> yeah i am
13:21 <Shiz> i want to upstream static-pie.patch too
13:21 <Shiz> but yeah the patches are kind of order-dependent atm
13:52 minimalism joined
14:02 <jirutka> Shiz: changes in patches done
14:02 <jirutka> Shiz: what about your new patch? :)
14:03 <Shiz> weeding out some issues..
14:03 <Shiz> error: cannot produce dylib for `rustdoc v0.0.0 (file:///home/builder/aports/testing/rust/src/rustc-1.16.0-src/src/librustdoc)` as the target `x86_64-unknown-linux-musl` does not support these crate types
14:03 <Shiz> :P
14:05 <jirutka> Shiz: I have an idea… what if we create new profile, $arch-alpine-linux-musl, with dynamic linking as default, and keep unknown-linux-musl with static linking as default?
14:05 <Shiz> i have thought of that, but it seemed... invasive?
14:06 <jirutka> Shiz: maybe it’d be more convenience than -C target-feature=[+-]crt-static
14:06 <jirutka> Shiz: I’d be more convenience in abuilds, because our triple is x86_64-alpine-linux-musl
14:06 <jirutka> Shiz: now we must change it to x86_64-unknown-linux-musl
14:07 <jirutka> for rust stuff
14:07 <jirutka> hm, no, this would not work
14:07 fabled joined
14:07 <jirutka> b/c /usr/lib/rustlib/<TARGET>…
14:07 <Shiz> :P
14:08 <Shiz> i mean that part would work fine
14:08 <Shiz> since we only distrib dynamically linked binaries for alpine, right
14:08 <Shiz> if people wanna do normal or even static, it wouldnt affect it
14:08 <Shiz> only if they do -C prefer-dynamic, at that point you're not portable ANYWAY
14:09 <jirutka> I think that I didn’t get your point now…?
14:11 <jirutka> eh, screw it, this is not important issue
14:13 <Shiz> my point is, changing the target is fine for rustlib
14:13 <Shiz> i don't see why it'd be an issue there?
14:55 rnalrd joined
15:01 squaremo joined
15:01 fabled_ joined
15:03 <jirutka> please, someone, fix qt5-qtscript, it’s blocking armhf for several days…
15:04 dmp42__ joined
15:05 robtec_ joined
15:06 nmeum_ joined
15:06 Klowner_ joined
15:09 mattjbar- joined
15:09 esmiurium_ joined
15:09 sigjuice_ joined
15:10 tg` joined
15:10 scadu_ joined
15:13 jakedt joined
15:13 ashb joined
15:33 <jirutka> kaniini: we should really somehow get founding from docker… that’s how (most?) people see what we are doing here… :/ https://twitter.com/rhy0lite/status/852527145746345984
15:35 <jirutka> s/founding/funding/
15:38 leo-unglaub joined
15:39 <jirutka> leo-unglaub: hi! we have great news for you!
15:39 <leo-unglaub> jirutka: really?
15:39 <leo-unglaub> diched the linux kernel for an openbsd kernel? ;)
15:40 <jirutka> leo-unglaub: yeah! thanks to Shiz we have fully working rustc with support for both dynamic PIE and static PIE linking on Alpine!
15:40 <jirutka> leo-unglaub: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rust
15:40 <leo-unglaub> very nice work !
15:41 <jirutka> leo-unglaub: our rustc use dynamic linking by default, but you can switch it to static using `-C target-feature=+crt-static`
15:41 <leo-unglaub> damn, have to go
15:41 <jirutka> leo-unglaub: and that will produce statically linked PIE binary!
15:42 <jirutka> leo-unglaub: it required a lot of effort, we found many bugs/issues in Rust build system…
15:42 <jirutka> leo-unglaub: you may be also interested in this excellent post by Shiz https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085
15:43 <jirutka> leo-unglaub: I believe that we will be able to push rust and cargo into community before branching v3.6
16:13 tg joined
16:30 <rdutra> ncopa: to fix the go package in ppc64le, we will need to generate a go 1.8 apk and upload it to somewhere to be able to compile go.
16:30 <rdutra> The problem is that go-bootstrap 1.4 version (that is the last version that does not have go code) is not supported in power, so we had to do a cross-compilation
16:32 ncopa joined
16:32 ncopa joined
16:32 fcolista joined
16:34 YoursTruly joined
16:34 dmp42_ joined
17:27 <leitao> Dear experts, what a dot "." means at APKBUILD? I found it at community/libevhtp/APKBUILD.
17:27 <leitao> http://tpaste.us/bKPB
17:27 <leitao> it seems to FTBFS on ppc64le
17:28 <TemptorSent> '.' = source in shell script.
17:29 <TemptorSent> Although the usage in the referenced file is very strange indeed.
17:29 <leitao> it seems that '.' is located in a single line
17:29 <leitao> TemptorSent, yup
17:29 <leitao> it is there since the beginning.
17:30 <TemptorSent> Hmm, source with no args...
17:30 <leitao> Ahh
17:30 <leitao> it is being escaped.
17:30 <leitao> it should be part of cmake line?
17:31 <leitao> no, there is an empty line between both.
17:31 <TemptorSent> No, it looks like there's an extra line..
17:31 <leitao> right
17:31 <leitao> yea, I am not smart enough to understand it.
17:31 <TemptorSent> I think it was intentended to be cmake command in current dir.
17:32 <TemptorSent> But someone added some spacing?
17:32 <TemptorSent> Try it with it following the last escaped line
17:32 <leitao> sure
17:33 <leitao> it works
17:33 <leitao> http://tpaste.us/7BE1
17:33 <TemptorSent> ./ would be better perhaps, but sometimes the trailing slash confuses things.
17:33 <leitao> it seems that ncopa added that line
17:34 <TemptorSent> Yeah, looks like a random newline got in there :)
17:34 <leitao> I am assuming that this is a regression, and push this fix
17:34 <TemptorSent> It was supposed to be immediately following the previous \ escaped line for clarity I believe.
17:35 <leitao> yea
17:35 fabled__ joined
17:35 <TemptorSent> I'd do that, rather than simply appending it to the previous line.
17:36 <TemptorSent> Hello fabled__?
17:36 fabled joined
17:48 tty` joined
17:57 <kaniini> it's weekend man
18:04 <jirutka> no, it’s not (ye) :P
18:04 <jirutka> yet
18:05 <hiro> no it is for me
18:05 fabled joined
18:06 <scadu> hiro: lucky you
18:18 BitL0G1c joined
18:38 <jirutka> Shiz: okay I know how to deal with Rust pkgs :)
18:53 <ncopa> leitao: hte dot means "current directory"
18:53 <ncopa> look like it is suppsed to be cmake -DBLA_BLA .
18:53 <leitao> ncopa, yes, i just fixed it.
18:54 <ncopa> thanks for cleanin up my mess :)
18:55 <leitao> ncopa, no worries, by the way, it seems that we are reaching an end in the community archive
18:55 <ncopa> \o/
18:55 <algitbot> \o/
18:55 <leitao> I hope to start working on testing next week
18:55 <ncopa> good
18:55 <ncopa> testing is not that critical, at least not for 3.6 release
18:56 <leitao> right
18:56 <ncopa> but it would be nice to have it cleaned up
18:56 <leitao> is 3.6 still scheduled for 5/1?
18:56 <ncopa> if you have something thats broken, and nobody has touched it for more than 6 months
18:56 <ncopa> in testing
18:56 <^7heo> ncopa: speaking of testing, I'm gonna have to try again to install the computer with the detached header this week end.
18:56 <^7heo> (not @testing, but the verb)
18:56 <ncopa> and it looks like its non-trivial
18:57 <ncopa> then we can move it to unmaintained
18:57 <leitao> ncopa, ok
18:57 <ncopa> also
18:57 <ncopa> the stuff we have in unmaintained
18:57 <ncopa> thats older than 6months
18:57 <ncopa> should be pruged
18:57 <ncopa> the "unmaintained" is like trashcan :)
18:58 <ncopa> ^7heo: great
18:59 <TemptorSent> ^7heo: Do you have that refined script handy? I'm about finished with the nasty part (kernel/module/firmware mess) and ready to remove the last vestiges of the broken mkinitfs behavior.
19:00 <leitao> ncopa, by the way, the current package that fails on ppc64le is obnam
19:00 <leitao> it depends on a package that was not in the archive before.
19:00 <^7heo> TemptorSent: what do you mean?
19:00 <leitao> I added it at testing/py-packaging
19:00 <leitao> should it be moved to community?
19:01 <leitao> or I can cross reference dependencies?
19:01 <TemptorSent> ^7heo: The one you used for deps and the rest of whats needed to make the detached header function properly.
19:02 <TemptorSent> I have it fixed so we won't get broken modules any longer without really trying :)
19:03 <^7heo> TemptorSent: dude I'm working; I have no time to try X times to re-read what you wrote to make sense of it.
19:03 <^7heo> TemptorSent: sorry =/
19:03 <awilfox> ^7heo: <TemptorSent> Do you have the script you used to make the detached header work? I want to see it
19:04 <awilfox> that's how I read it, anyway
19:06 <TemptorSent> ^7heo: Sorry, I would like to know what changes you needed to make and what commands you use to generate a working detached-headder configuration once you get it done.
19:06 <jirutka> what detached header?
19:06 <leitao> I know detached head, from git if it works.
19:06 <TemptorSent> ^7heo: And include any fixes that might be needed in mkinitfs itself.
19:07 <TemptorSent> LUKS
19:08 <TemptorSent> Essentially, leaving the entire disk encrypted with no interesting plaintext because you carry the 'detacthed' headders on a usb key.
19:08 <ncopa> leitao: packages can only depend from same repo or main
19:09 <ncopa> testing can depend on both main or community
19:09 <ncopa> its weekend here now
19:09 <ncopa> have a nice evening!
19:09 <TemptorSent> This is something I very much would like to support, so if anything is missing to make it generally workable, I'd like to get that addressed asap.
19:09 <TemptorSent> ncopa: Have a great weekend.
19:12 <jirutka> leitao: to be more formal, repositories are in hierarchy: main < community < testing; pkgs in repo X can depend on pkgs in X and all repos on left from X, but not on right from X
19:12 <jirutka> ncopa: nice weekend and Easter!
19:15 <^7heo> awilfox: thanks ;)
19:15 <^7heo> TemptorSent: there was no such script.
19:16 <awilfox> huh, is Friday a holiday in Europe?
19:16 <^7heo> at least in .de
19:16 <awilfox> it definitely isn't here (though it is my birthday!)
19:16 <TemptorSent> Long weekend for easter.
19:16 <TemptorSent> Happy Birthday!
19:16 <^7heo> TemptorSent: to make the detached header work I used my brain and vi.
19:16 <^7heo> TemptorSent: not a script.
19:16 <^7heo> TemptorSent: I still don't get what you want.
19:16 <^7heo> and yes
19:16 <^7heo> awilfox: HAPPY BIRTHDAY! ;)
19:16 <jirutka> awilfox: in some countries
19:16 <TemptorSent> ^7heo: What does it need to BOOT, as far as any changes to initramfs-init
19:16 <leitao> jirutka, ok, makes sense.
19:16 <awilfox> ^7heo: thanks :3
19:17 <leitao> there is one package in community called obnam that "depends" on py-packaging.
19:17 <^7heo> TemptorSent: aah, you mean, what did I need to change to the script to make it work?
19:17 <TemptorSent> Yes :)
19:17 <leitao> jirutka, i.e, it is not marked as a dependency, but obnam does not compile if you do not have py-packaging installed.
19:18 <jirutka> awilfox: it’s Good Friday (also referred as Easter Friday); for example in Czech Republic this became a state holiday just few years ago
19:18 <jirutka> awilfox: and happy birthday to you!
19:18 <TemptorSent> ^7heo: I want to generate the initfs so it just works.
19:18 <leitao> jirutka, should we migrate py-packaging to community and make obnam dependent of py-packaging?
19:19 <jirutka> leitao: yes, but please open a PR for it; I see some issues in this package
19:19 <jirutka> hm, like, many issues :/
19:19 <jirutka> leitao: do you know https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python ?
19:20 <leitao> jirutka, ok, I will review this package before opening a PR.
19:21 <^7heo> TemptorSent: https://github.com/alpinelinux/mkinitfs/commit/5ee279f6b475306659af256f724847c65b335040
19:21 <TemptorSent> ^7heo: And if you have the list of deps, you needed to install in the initfs a well, that would be quite helpful..
19:21 <TemptorSent> TY
19:22 <TemptorSent> ^7heo: We are pretty close to splitting nlplug-findfs to it's own package and moving the mkalpine tools to a top level repo
19:25 <awilfox> jirutka: I see. also, thanks!
19:25 <TemptorSent> ^7heo: Okay, very, very minor changes required - just passing along the correct cryptopts for cryptheader and cryptoffset it appears.
19:30 <^7heo> yes
19:32 consus joined
19:37 feepo joined
19:46 terra joined
19:55 <terra> Guys, what is the procedure for taking over an unmaintained package? Should I contact with maintainer first?
19:58 <^7heo> yeah.
19:58 <^7heo> what's the package?
20:01 cyteen joined
20:12 boingolo1 joined
20:15 dmp42_ joined
20:21 blueness joined
20:23 blueness joined
20:43 <Shiz> jirutka: oh?
21:12 <terra> ^7heo: unmaintained/vdr
21:26 <jirutka> terra: you don’t need to ask for pkgs in unmaintained
21:26 <jirutka> Shiz: ?
22:58 LongyanG joined
23:17 BitL0G1c joined
23:58 <Shiz> jirutka: jirutka │ Shiz: okay I know how to deal with Rust pkgs :)
23:59 terra joined