<    June 2018     >
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 _2_2 23  
24 25 26 27 28 29 30
01:18 <hanez> just playing around with the idea of reproducible builds. i need to set the timestamp to all files in a package after package() in the APKBUILD was executed. i play a lot around with the abuild code but can't figure out where to that. any idea anyone who is deep into abuild code?
01:41 wener joined
01:42 wener joined
01:44 czart__ joined
01:55 <hanez> okay i got that... now i need to know at which place the public RSA key is added to the package... any help would be nice. i am confused... :))
02:02 <hanez> got it...
02:22 tmh1999 joined
03:56 mickibm joined
05:29 kolbyjack joined
06:06 rdutra joined
06:23 mickibm joined
06:49 <clandmeter> ncopa, looks like rpi images work fine.
06:50 <clandmeter> thx for the firmware change.
06:50 <clandmeter> need to get latest firmware added.
06:55 JayBau joined
07:02 Fusl joined
07:05 <ncopa> i wonder if we should decouple linux-firmware from kernel
07:05 <ncopa> i dont know how though
07:05 <ncopa> becuase if if simply remoev the dep, then will people have problems when upgrade
07:06 <ncopa> maybe wait til after v3.8
07:06 JayBau joined
07:11 <ncopa> we need to fix those: http://tpaste.us/N7eB
07:16 JayBau joined
07:19 JayBau joined
07:26 JayBau joined
07:31 JayBau joined
07:31 JayBau joined
07:32 <ncopa> i have a tool for checking open github PRs for the aport you has a working directory
07:32 <ncopa> so if you cd main/package
07:32 <ncopa> and aports-ghpr
07:32 <ncopa> it will search open PRs
07:33 <ncopa> https://git.alpinelinux.org/cgit/user/ncopa/aports-ghpr/
07:33 clemens31 joined
07:39 JayBau joined
07:40 <mepholic> ncopa: hmmm? decouple how?
07:40 <mepholic> is it in the same package on alpine? i thought there was a separate linux-firmare package
07:41 JayBau joined
07:46 <ncopa> there is a separate linux-firmware package
07:46 <ncopa> which depends on a bunch of linux-firmware-foobar pacakges
07:46 <ncopa> but linux-vainlla depends on linux-firmware
07:46 <ncopa> so you will always get all of the firmware installed
07:47 <ncopa> i would like to remove the linux-firmware dependency for linux-vanilla
07:47 <ncopa> and at install time, detect exactly which firmware is needed
07:47 <ncopa> and only pull in those
07:47 JayBau joined
07:48 <ncopa> or maybe install all of them, but make it possible manually remove some of the unused ones
07:52 <mps> ncopa: your last idea sounds like it is the most reasonable
07:53 <ncopa> the problem is that if we remove the linux-firmware dependency, it will get uninstalled when people upgrade
07:53 <ncopa> which may give people problems
07:54 JayBau joined
07:54 <ncopa> so what im thinking is
07:54 <mps> yes, install everything and get the system working, after that user/admin could remove what is not needed in his/her system
07:54 <ncopa> problem is when you upgrade
07:54 <ncopa> apk ugprade
07:55 <ncopa> if dependency is removed linux-firmware will be removed
07:55 <ncopa> and user will have to manually apk add it before rebooting
07:55 <ncopa> or network may break if they depend on firmware
07:55 <mps> maybe reinstall everything during upgrade?
07:56 <ncopa> people normally just do: apk upgrade
07:56 <ncopa> to upgrade their systems
07:56 <ncopa> without paying attention
07:56 <mps> and again user/admin could remove unneeded after upgrade
07:56 <ncopa> the problem is that upgrade will remove needed
07:57 <mps> not sure, just thinking aloud
07:57 <ncopa> im not sure you understand the upgrade problem
07:58 <ncopa> example
07:58 <ncopa> user has a machine with a NIC that rquires a firmware
07:58 <ncopa> user installed v3.7 or runs edge
07:58 <ncopa> currnetly the linux-vanilla depends=linux-firmware
07:59 <ncopa> user get linux-vanilla installed and linux-firmware
07:59 <mps> that is my case right now
07:59 <ncopa> everything works
07:59 <ncopa> now, what we are discussing is removing the depends=linux-firmware
07:59 <mps> I understand
08:00 <ncopa> if we simly remove the dependeny, an apk upgrade will remove the linux-firmware
08:00 <ncopa> if user does not pay attention and reboot
08:00 <ncopa> network will be broken
08:00 <mps> right, I know
08:00 <ncopa> but i may have an idea how to solve it
08:00 <ncopa> i am not sure it works though
08:00 <mps> I did right that, removed linux-firmware and noticed that
08:01 <ncopa> the idea is that we set provides=linux-firmware on all linux-firmware-$sub
08:01 <mps> my thought is that - install everything (firmware) at install or upgrade linux-vanilla (kernel)
08:02 <ncopa> we also add an linux-firmware-empty with provides=linux-firmware
08:02 <ncopa> and in the linux-vanilla we keep the depends=linux-firmware
08:03 <mps> that is ok
08:03 <ncopa> this means that you need any of the linux-firmware-* installed to make apk happy
08:03 <ncopa> if you have linux-firmware installed from before, then apk is happy
08:03 <mps> if linux-vanilla depends on linux-firmware then the linux-firmware must be installed
08:03 <ncopa> if you want finetune, then you can apk add linux-firmware-foo
08:04 <ncopa> and apk del linux-firmware
08:04 <ncopa> since linux-firmware-foo provides the linux-firmware, apk should be happy
08:05 <mps> but doesn't linux-firmware depends on all linux-firmware-xxx
08:05 <ncopa> it does
08:05 <ncopa> but i think it may work
08:05 <ncopa> alternatively we use another provides name
08:06 <mps> so removing just one linux-firmware-xxx will remove linux-firmware
08:06 <ncopa> the idea is that you first apk add linux-firmware-foo
08:07 <ncopa> then apk del linux-firmware (catch all package)
08:07 <mps> and linux-firmware 'will' remove all linux-firmware-xxx
08:07 <ncopa> you add linux-firmware-foo to /etc/apk/world
08:07 <ncopa> it becomes a top level dependency
08:08 <ncopa> when you apk del linux-firmware, it will delete all linux-firmware-* except the ones listed in world
08:08 <ncopa> the linux-firmware-foo which has provides=linux-firmware will satisfy the linux-vanilla's depends=linux-firmware
08:08 <ncopa> that is the idea
08:08 <mps> hmmm, maybe some kind of pinning desired linux-firmware-xx
08:08 <ncopa> that is what apk add linux-firmware-xx does
08:09 <ncopa> it will "pin" it
08:09 <ncopa> to world
08:09 <mps> aha, now understand better
08:09 <mps> that sounds good
08:09 <ncopa> linux-vanilla dependency will be met if any of the linux-firmware-* are installed
08:10 <ncopa> which of then doesnt matter
08:10 <ncopa> so the problem is: what happens if you dont need any firmware at all?
08:11 <ncopa> thats why i mentioned an empty package named linux-firmware-none
08:11 <mps> I can't remember any machine where at least some firmware is not needed
08:11 <mps> maybe some VMs
08:11 <ncopa> VMs yes
08:12 <mps> let me summarize
08:13 <mps> install linux-vanilla will install linux-firmware, which will install all linux-firmware-*
08:14 <mps> then, remove unneeded linux-firmware-x and rest of the linux-firmware-x will be 'pinned' for upgrade
08:14 <mps> right?
08:15 <ncopa> actually: apk add linux-vanilla will give error
08:15 <ncopa> you will have to pick one linux-firmware package
08:15 <ncopa> but upgrades will work
08:15 <ncopa> unless we give linux-frimware (the catchall) a prioritoy
08:16 <ncopa> then it should work
08:17 <ncopa> to summarize: on fresh install, linux-vanilla and linux-firmware-all is installed
08:17 <mps> that is ok
08:17 <ncopa> user who wants remove unneeded will need to: apk add liunx-firmware-foo && apk del linux-firmware-all
08:18 <ncopa> the first 'add' will pin it to worls
08:18 <mps> aha, good
08:18 <ncopa> the second will remove all unneeded
08:18 <ncopa> thats the idea
08:18 <mepholic> mps: out of curiosity, do you use tcsh as your main shell?
08:18 <mps> mepholic: yes, more that 25 years
08:19 <mepholic> ah nice :)
08:20 <mepholic> how's it treating you on alpine?
08:20 <mps> ncopa: so, apk add linux-firmware-foo1 will pin that package, and apk add linux-firmware-foo2 will pin it also
08:20 <ncopa> correct
08:21 <mepholic> lemme catch up on backlog since I asked my q to ncopa
08:21 <mps> that sounds good, till you find clever idea :)
08:21 <mps> last msg meant to ncopa
08:21 <ncopa> mps: i am not sure it will work in practice though
08:22 <ncopa> we may need use another name for the provides
08:22 <mps> ncopa: I thougt about that, but does apk understand 'provides' tag
08:23 <ncopa> yes
08:23 <mps> then it should work
08:23 <ncopa> i dont knkow if it works if you have a pkgname=linux-firmware and others with provides=linux-firmware
08:24 <ncopa> i guess i'll have to test it
08:25 <mps> if linux-firmware depends on the all linux-firmware-* how it could be 'told' to stop depending on removed ones
08:26 <ncopa> ok, to explain that better, lets say we use provides=anyfw
08:26 <ncopa> the linux-firmware which depends on linux-firmware-*, has a provides=anyfw
08:26 <ncopa> all the linux-firmware-* also has provides=anyfw
08:26 <ncopa> we change linux-vanilla to depend=anyfw
08:26 <mps> aha, ok
08:27 <mepholic> ncopa: I'm concerned that that still wont resolve the issue of linux-kernel depending on linux-firmware
08:27 <mepholic> or rather, you'd still need to remove the dep, yes?
08:27 <mepholic> and it'd still uninstall things from the users system if they haven't pinned specific firmwares already
08:28 <ncopa> lets use "anyfw" as provides name in this example
08:28 <ncopa> so current users has: linux-vanilla installed with depends=linux-firmware
08:28 <ncopa> so linux-firmware is installed due to the dep
08:28 <ncopa> we change linux-vanilla depends=anyfw
08:29 <mepholic> OH and linux-firmware provides anyfw
08:29 <mepholic> !
08:29 <ncopa> when users upgrade, then already have the linux-firmware installed so the dep is satisfied
08:29 <ncopa> that was the idea
08:29 <ncopa> but i dont know if it works
08:29 <mepholic> yeah, gotcha
08:29 <mepholic> sounds reasonable to me
08:30 <mps> also to me
08:31 <mps> of course, if the apk add firmware-foo1 automatically pins it
08:32 <mps> and apk del linux-firmware-foo1 unpins it
08:35 <mps> mepholic: what you mean by 'how's it treating you on alpine?' question?
08:35 JayBau joined
08:35 <mps> I'm self taught in English so I cannot catch some finesses
08:36 <awilfox> mps: I think that was basically asking "is it working well"
08:36 <mps> awilfox: yes, it works very well
08:37 <mps> I don't have any problem with it
08:39 fekepp joined
08:40 <mepholic> mps: I realized after the fact that I really need to avoid using colloquialisms with people I know are foreigners
08:40 <mepholic> :P
08:41 <mepholic> also, it's impressive to me that some people have been using the same software for as long as I've been alive
08:41 <mepholic> "so by 'legacy', you mean that 'it works'?" :D
08:41 <mps> mepholic: 'cat' is longer here that tcsh
08:41 <mps> :)
08:42 <mepholic> now the real question is if you've used the same implementation of 'cat' the whole time
08:42 <mepholic> :P
08:43 <ncopa> re linux-firmware
08:43 <ncopa> i think it works
08:43 <mepholic> nice :D
08:43 <ncopa> and i think it works better than i thought
08:43 <ncopa> you simply need to apk add linux-firmware-xx
08:43 <ncopa> and it will purge linux-firmware
08:43 <mepholic> is that a feature though?
08:43 <mepholic> I mean I guess it is
08:43 <ncopa> yes
08:43 <awilfox> I just read how you're doing it; that's how we got alpine<->adelie crossgrades to work with libressl/openssl
08:44 <awilfox> exactly that way
08:44 <ncopa> the only thing i noticed was that with the apk ugprade, it would only upgrade the main package, not the subpackages
08:45 <ncopa> i think that can be solved with versioned deps
08:45 <mepholic> can you version subpackages?
08:45 <ncopa> versioned dependency of subpackage yes
08:45 <mepholic> i figure'd they'd have inherited the main packages version
08:46 <ncopa> depends="subpkg=$pkgver-$pkgrel"
08:46 <ncopa> specify the version in the depends
08:46 <mepholic> so the question is, is THAT a feature?
08:47 <ncopa> versioned dependencies?
08:47 <ncopa> yes
08:47 <mepholic> why would you potentially want stale subpackages hanging around?
08:47 <mepholic> or maybe I'm failing to understand something
08:47 <awilfox> clamav has something like that I think
08:47 <ncopa> the problem is that when i added provides=... on all the subpackages, and did apk upgrade
08:48 <awilfox> freshclan-openrc deps on freshclam=$pkgver
08:48 <ncopa> it didnt upgrade the subpackags
08:48 <awilfox> well -$pkgrel too
08:50 <ncopa> ok that gave error
08:51 fekepp joined
08:56 <ncopa> ok, it does not work :-(
08:56 <ncopa> well
08:56 <ncopa> it sort of works
08:56 <ncopa> apk upgrade will give error
08:58 <ncopa> so basically, user will get error and will have to apk add linux-firwmare-something
08:58 <ncopa> i guess that sort of works
08:58 <ncopa> because then will user not unintentionally get the firmware removed
09:00 <mps> that is ok, IMO
09:04 <ncopa> and it is solvable
09:05 <ncopa> this is great
09:05 <ncopa> if we set provider_priority=1 on the main package
09:05 <ncopa> then it will autopick that
09:05 <ncopa> so you will get the linux-firmware
09:05 <ncopa> unless you pick a specific
09:06 <ncopa> if you apk add linux-firmware-foo
09:06 <ncopa> it will add that and purge the rest
09:07 <ncopa> it works perfect
09:07 <mps> and, apk add linux-firmware-foo ; add linux-firmware-bar it will keep both?
09:07 <ncopa> yes
09:07 <ncopa> and only those
09:07 <mps> nice
09:07 <ncopa> we only need a dummy package for -none
09:09 <mps> so, linux-firmware-none will remove all firmware?
09:09 <ncopa> and install an empty package, yes
09:10 <mps> useful for VMs
09:11 <mps> ncopa: good work
09:18 stateless joined
09:28 <mepholic> :)
09:28 <mepholic> awesome!
09:28 pickfire joined
09:29 JayBau joined
09:29 <ncopa> now i just wait for kernel version upgrade to avoid build it twice
09:29 <ncopa> wait for 4.14.50
09:48 _JayBau_ joined
10:06 <strfry> ncopa: excellent, also thank you very much for the quick linux-rpi change :)
10:25 leo-unglaub joined
10:46 wener joined
10:50 agowa338 joined
10:52 fekepp joined
10:55 wener_ joined
11:05 wener joined
11:11 wener joined
12:22 wener joined
12:41 fabled joined
13:04 mizux joined
13:44 Topic for
13:55 <tmh1999> ncopa: I guess you'd like to release next week ?
13:55 fekepp joined
13:55 <tmh1999> it's friday.
14:19 JayBau joined
14:28 JayBau joined
14:30 <ncopa> yes
14:30 <ncopa> early next week is release
14:30 <ncopa> i was hoping that 4.14.50 comes out first
14:32 StarWarsFan|afk joined
14:41 JayBau joined
14:59 <tmh1999> +1
16:24 mickibm joined
16:39 <ncopa> Clandmeter: the netboot symlink is there
16:40 <ncopa> I think we should add versions to the ipxe menu
16:41 <clandmeter> Hi
16:41 <clandmeter> How do you want to add it?
16:43 <clandmeter> Ipxe is limited
16:47 <ncopa> You add the urls in the ipxe config, right? What if we generate the config?
16:49 <ncopa> Hook on mqtt release event we generate the ipxe config
16:49 <hanez> ncopa: do you have an idea why --mtime is not working here? (line 34 in abuild-sign.in) : tar --mtime='1970-01-01' -f - -c "$sig" | abuild-tar --cut | gzip -9 > "$tmptargz"
16:49 <ncopa> Using mustache template or similar
16:51 <ncopa> How do you define not working?
16:52 <clandmeter> Generate scripts will work
16:52 <clandmeter> I can check later
16:52 <ncopa> Doesn't the timestamp show 1970 when you tar -ztvf ..?
16:52 <clandmeter> Had a funeral today :|
16:53 <ncopa> Aw!
16:53 <hanez> ncopa: it will be ignored. i have added --mtime there but it still sets the build time and date for the $sig file in the .apk
16:53 <hanez> not what i defined in --mtime
16:53 <hanez> in abuild.in it works at the two places where tar is being called
16:54 <ncopa> and if you pipe it to tar? ... | tar -tv
16:54 <ncopa> Note that gzip also store a timestamp
16:55 <hanez> i am trying to play around with reproducible package builds and the timestamp of files is often a problem... it's just a proof of concept at the moent and i will post all my ideas on the mailinglist for discussion when it works
16:55 <hanez> ncopa: yeah, but in abuild.in it works
16:55 <hanez> and the call is teh same
16:55 <hanez> you mean pipe tar to tar?
16:55 <ncopa> Yes
16:55 <hanez> okay... i will giveit a try
16:56 <ncopa> To see if it is tar or something else
16:56 <hanez> yep. are you aware of the idea of reproducible builds?
17:32 <hanez> hm, tar can not read from stdin so piping from tar to tar will not work
17:32 <hanez> i am confused
17:34 <TBB> which tar is it?
17:34 <hanez> GNU tar
17:34 <hanez> what i am trying is to set --mtime
17:35 <hanez> this works in abuild.in: tar --mtime='1970-01-01' -f - -c $(cat "$dir"/.metafiles) | abuild-tar --cut | gzip -9 > control.tar.gz
17:35 <hanez> but this does not work in abuild-sign: tar --mtime='1970-01-01' -f - -c "$sig" | abuild-tar --cut |
17:35 <hanez> gzip -9 > "$tmptargz"
17:51 <ncopa> $ tar --mtime='1970-01-01' -c foo | tar -tv
17:51 <ncopa> -rw-r--r-- ncopa/ncopa 13 1970-01-01 00:00 foo
17:52 <ncopa> $ tar --mtime='1970-01-01' -c foo | abuild-tar --cut | tar -tv
17:52 <ncopa> -rw-r--r-- ncopa/ncopa 13 1970-01-01 00:00 foo
17:54 <hanez> uh, thanks
17:54 <hanez> i will try that
17:55 <ncopa> you can remove "-f -"
17:55 <ncopa> is the same as not specifying -f
17:57 <hanez> hm, but the .SIGN.RSA* ist still todays date after running: tar --mtime='1970-01-01' -c "$sig" | tar -tv | abuild-tar --cut | gzip -9 > "$tmptargz"
17:57 <hanez> it should be 19700101000000
17:57 <hanez> sorry, 19790101000000
17:58 <hanez> argh
17:59 <ncopa> been thinking of reproduceable builds and timestamps
17:59 <ncopa> we could use the git commit timestamp
17:59 <hanez> yep
17:59 <hanez> yes, thats the idea
17:59 <ncopa> good :)
17:59 <hanez> i am hard setting it to 1970-01-01 00:00:00 hard ATM
18:00 <ncopa> you also need to set gzip timestamp
18:00 <hanez> it should be the last git commitz date at some time
18:00 <hanez> thje timestamp of the gzip is not so important at first
18:00 <hanez> i need to get the .SIGN.RSA* set to a specific date
18:01 <ncopa> it is abuild sign that creates it, right?
18:01 <hanez> all other files are set correct within the abuild script but in the signing process it fails
18:01 <hanez> yes
18:02 <ncopa> and we dont sign via pipe?
18:02 <hanez> this looks it for me now: https://pastebin.com/uDcCefpH
18:02 <ncopa> then we could make abuild sign keep the date of the original file
18:03 <hanez> that would be nice too
18:03 <ncopa> tar --mtime='1970-01-01' -c "$sig" | tar -tv | abuild-tar --cut | gzip -9 > "$tmptargz"
18:03 <ncopa> thats wrong
18:04 <ncopa> remove the tar -tv
18:05 <hanez> yes, but that still sets the timestamp of the .SIGN.RSA* to today and not 19700101
18:06 <[[sroracle]]> yes
18:07 <[[sroracle]]> you need to look at abuild-sign
18:07 <hanez> i said, in abuild script it works when building data.tar.gz andd control.tar.gz
18:07 <[[sroracle]]> that adds .SIGN file
18:07 <hanez> i know
18:07 <hanez> there i am hacking in
18:07 <hanez> i added --mtime to tar in abuild-sign
18:08 <hanez> as i said... in abuild script it works with just adding --mtime
18:08 <[[sroracle]]> libarchive tar doesn't support mtime so i just used touch instead
18:09 <hanez> what i said. in abuild script it works
18:09 <hanez> uh
18:09 <hanez> abuild uses /bin/ash and abuild sign /bin/sh
18:10 <hanez> thats the problem i think
18:11 <hanez> no
18:11 <hanez> it isnt
18:20 <hanez> touching the file $sig before tar'ing it doesn't help
18:20 <hanez> i am so confused
18:22 <[[sroracle]]> it's still today's date?
18:23 <hanez> yes
18:23 <hanez> i think i am stupid actually
18:24 <[[sroracle]]> i think i had the same issue where i was touching it before tar but also before openssl
18:24 <[[sroracle]]> need to touch after openssl
18:24 <hanez> yes, i do that after openssl
18:24 <hanez> did you worked on the idea of reproducable buils too?
18:25 <[[sroracle]]> yeah but i have barely scratched the surface as well :)
18:26 <hanez> i will get it working. i know some devs who invented it at debian and they would be happy to see alpine participate... ;)
18:26 <hanez> this is how it looks for me now: https://pastebin.com/JArsjPtR
18:27 <[[sroracle]]> my current thinking is to set SOURCE_DATE_EPOCH to either last commit time of APKBUILD or, if APKBUILD is dirty (uncommitted changes etc) then use stat APKBUILD
18:27 <hanez> i am touching and using --mtime with no luck
18:28 <hanez> yeah, thats the idea. i am at first want to reset it to 1970-01-01
18:28 <hanez> then the next step
18:29 <hanez> in debian they use the last change date of of the source files...
18:36 marketzero joined
18:47 <hanez> i am soooooo stupid
18:55 <hanez> will tell you later... git it now
18:55 <_ikke_> the suspension
18:57 <hanez> short, it was a calll to the wron abuild-sign script... /o\
18:57 <marketzero> I know the feeling
18:58 <ncopa> ha \o/
18:58 <algitbot> \o/
18:59 <ncopa> hanez: i've done similar....
18:59 <mickibm> is it necessary to provide an apkovl as a kernel boot argument in order to PXE boot?
18:59 <hanez> oh, thanks... feeling better now. i was short before shooting myself... :|
19:06 <mickibm> on ppc64le, using a power8 box, only when an apkovl is provided, then networking is configured properly. without apkovl, but still with same repo specified, cannot load initramfs and kernel panic
19:15 <hanez> okay... got muy first reproducible package... :)
19:19 mizux_ joined
19:20 <ncopa> mickibm: shoudl be possible to load initramfs even without apkovl
19:24 <mickibm> thats what i thought
19:34 wener joined
20:30 fekepp joined
20:50 tty joined
20:54 tmh1999 joined
21:55 <hanez> [[sroracle]]: ping
21:56 <[[sroracle]]> hanez: pong
21:56 <hanez> [[sroracle]]: getting the date from stat APKBUILD is not working because it always has the timestamp from cloning or checkout
21:56 <hanez> getting the date from last git commit of APKBUILD is not trivial too
21:57 <[[sroracle]]> right, so you default to getting the commit or author date first if APKBUILD has not been modified in the eyes of git
21:57 <[[sroracle]]> let me paste what i have
21:57 <hanez> yeah, that would be nice
21:58 <hanez> what i have so far. everything is working like we want it. expect the source for the date. currently it is still hardcoded
21:58 <hanez> but everything else works like a charm
21:58 <[[sroracle]]> http://ix.io/1duN
21:59 <[[sroracle]]> git status --porcelain will be empty iff APKBUILD is unmodified and previously committed
21:59 <[[sroracle]]> if it is modified or untracked then it outputs a status of some kind that you could examine further if you'd like
21:59 <[[sroracle]]> but in that case i just fall back to stat
22:00 <[[sroracle]]> %ct is for commit timestamp; you could also use %at for author timestamp
22:00 <hanez> are these unix timestamps?
22:00 <[[sroracle]]> they should be yes
22:01 <hanez> okay. where in abuild would you place that piece of code?
22:01 <[[sroracle]]> towards the end; probably before sourcing $APKBUILD itself
22:06 <hanez> okay, makes sense. what about line 2547 in https://git.unixpeople.org/hanez/abuild/src/branch/master/abuild.in ?
22:09 <hanez> 2565 is the better place because we the cd'ed to the right dir
22:10 <hanez> or after 2563
22:10 <hanez> then source APKBUILD
22:17 <hanez> hmm, git log does not work with busybox...
22:17 <hanez> less: unrecognized option: F
22:18 <mps> hanez: apk add less
22:19 <mps> busybox applets are 'first aid tools' and not useful for 'serious' work
22:20 <hanez> mps: okay, so less is available on build hosts?
22:20 <mps> apk search less will show you
22:20 <mps> ah, you are working on build host, sorry
22:20 <hanez> yes, i know.
22:21 <hanez> no, i am working on abuild
22:21 <mps> I thought you are working on the local machine
22:21 <hanez> and then less will become a dep of abuild
22:21 <awilfox> `git` should probably depend on `less`
22:21 <awilfox> honestly
22:21 <hanez> i am working local but hacking on abuild
22:21 <hanez> awilfox: yeah, you're right
22:22 <hanez> i really need the last commit date of an APKBUILD file for setting it as SOURCE_DATE_EPOCH for realizing reproducible builds
22:24 mickibm joined
22:29 <hanez> [[sroracle]]: i think this line should be enough: SOURCE_DATE_EPOCH=$($git log -1 --format='%ct' "abuild.in")
22:30 <hanez> s/abuld.in/APKBUILD/
22:31 <hanez> s/abuild.in/$APKBUILD/
22:31 <hanez> works so far
22:31 <mps> git log --pretty=format:'%ci' APKBUILD
22:32 <hanez> mps: nono, i need the unixtimestamp
22:32 <hanez> SOURCE_DATE_EPOCH _MUST_ be epoch time
22:33 <mps> ah, then %ct is right
22:33 <hanez> :)
22:33 <hanez> i am converting where needed
22:41 <hanez> \o/ it works... :)))
22:41 <algitbot> \o/
22:43 <mps> wireguard kernel module is in linux-vanilla but wireguard-tools is in testing
22:44 <mps> shouldn't the wireguard-tools be moved to main or to community at least
22:44 <hanez> the change now is: builddate, file dates in packages and the date in the header of PKGINFO file is set to the date of the last commit of the APKBUILD file
23:10 wener joined
23:14 _ikke_ joined
23:32 Fusl joined
23:44 czart_ joined
23:45 _ikke_ joined