On 2/19/19 7:20 AM, Michael Lojkovic via arch-general wrote:

The only thing I can think of, which applies to Arch is implementing remakepkg features in pacman. I was going to add those in when I got around to it, but it's also worth doing for Google Summer of Code.

https://bbs.archlinux.org/viewtopic.php?id=236076

remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell. This is a terrible idea. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 2/19/19 10:19 AM, Tinu Weber wrote:

On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:

...

remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.

The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.

In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)

(that being said, I'm obviously open for discussing suggestions)

I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz -- Eli Schwartz Bug Wrangler and Trusted User

On 2/19/19 11:26 AM, Tinu Weber wrote:

On Tue, Feb 19, 2019 at 10:22:34 -0500, Eli Schwartz via arch-general wrote:

...

On 2/19/19 10:19 AM, Tinu Weber wrote:

...

On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:

...

remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.

The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.

In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)

(that being said, I'm obviously open for discussing suggestions)

I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz

I was thinking more of: "If I run remakepkg twice on the same package, with the same rules, do I get the same output package?".

I just checked, and I do indeed modify the timestamp of a file when patching it (both the file itself and its MTREE entry), and I don't respect SOURCE_DATE_EPOCH, so I would conclude that remakepkg does not produce reproducible .pkg.tar.xz files.

That's a fair point. If you wanted to have remakepkg be a program that supported reproducible builds, it would need to respect some form of SOURCE_DATE_EPOCH -- I suggest using the builddate that the original .pkg.tar.xz used. As well, provide some mechanism for https://reproducible-builds.org/docs/recording/ the input (the .pkg.tar.xz and the deviations that have been declared). The difference is that it is hardly an issue if remakepkg invalidates the makepkg .BUILDINFO spec, since remakepkg is not makepkg and isn't expected to produce the same output as makepkg anyway -- it is only meant to produce output that *pacman/libalpm* can consume. -- Eli Schwartz Bug Wrangler and Trusted User

On 2/19/19 1:20 AM, Michael Lojkovic via arch-general wrote:

On Sat, 2 Feb 2019 20:51:37 +0530 Aniket Pradhan wrote:

...

Hello Govind, and Everyone!

Thanks for your feedback.

Your arguments are on point, and I agree with you on the fact that the ideas do not apply to Arch.

If we can think of some better ideas (which apply to Arch, like the reproducible builds or the CLI tool as you discussed) we would need people to step up and mentor these ideas out of their free time. Moreover, if Arch is willing to include some community tools (who decides which tools should be included), we might get some more cool ideas, but in the end, we would also need someone to mentor the idea.

In the end, it all boils down to the availability of mentors. and ideas.

I also had this cool idea, where developers (who will act as mentors) can pitch in their ideas for community packages and select students through GSoC. This will provide them with the necessary help in developing the tool. However, then it would not be a "community-driven" package, would it?

There can be several flaws to this suggestion, but as Govind said, it would be amazing if others can share their opinion on this topic.

The only thing I can think of, which applies to Arch is implementing remakepkg features in pacman. I was going to add those in when I got around to it, but it's also worth doing for Google Summer of Code.

https://bbs.archlinux.org/viewtopic.php?id=236076

You need the Google Summer of Code to implement an external tool that has already been implemented? Who told you to declare that this is definitively a desired, guaranteed-to-be-accepted feature, moreso that it is the only outstanding feature for the pacman project? We have 219 outstanding bug reports and feature requests, some of which would implement valuable safety features like aborting gracefully (rather than crashing after invalidating your system) if the user does something unwise like overwrite /var/cache/pacman/pkg with a symbolic link. "People want to know what they could do for Arch for GSOC", and you advertise some personal interest as being representative of the only thing you think Arch needs? When people have already mentioned things like pacman itself (see the aforementioned 219 bugtracker tickets), the build system and reproducible builds efforts, the security tracker... "The only thing I can think of which applies to Arch" is something no one has ever requested be added to makepkg, and furthermore -- it is out of scope. makepkg builds packages based on source code, remakepkg mutates existing ones in a manner that is not applicable to PKGBUILDs. makepkg can already --repackage your build directory with a modified PKGBUILD, if you ask it to, which is in scope for makepkg because it just involves picking up a makepkg build halfway through. Seems to me like remakepkg is already a perfectly suitable thirdparty tool that shares no commonality with makepkg, hence why it is a *thirdparty utility* -- and pacman is not the canonical provider of thirdparty utilities. Nor should it be -- if the primary "person who cares" about the tool does not regularly interact with the pacman-dev mailing list, the code would simply rot as part of pacman, and furthermore, even if it did see active development in the pacman tree, it would be forced to conform to the slower release cycle of pacman for no reason. -- Eli Schwartz Bug Wrangler and Trusted User