Re: [arch-dev-public] Restricting ability to post news items

2020-01-05 Thread Johannes Löthberg via arch-dev-public

Excerpts from Allan McRae via arch-dev-public's message of January 5, 2020 
23:27:

After the base metapackage pile of crap that was posted, I (and others)
reminded everyone of the process that had been held for years.

The response was complaints that this process was not followed recently,
to which we pointed at the arch-dev-public mailing list post for
multiple non-trivial news entries.  Only simple "--overwrite" type posts
have not been posted on arch-dev-public.



Where was this reminding done?  Because the only thing I can find about 
it is logs from #archlinux-dev.  Can't find anything announced on any of 
the mailing lists nor in #archlinux-tu.

--
Sincerely,
 Johannes Löthberg :: SA0DEM


pgpJlYaHGjpe9.pgp
Description: PGP signature


Re: [arch-dev-public] Merging multilib toolchain with [core]

2017-11-22 Thread Johannes Löthberg via arch-dev-public
Quoting Bartłomiej Piotrowski (2017-11-22 12:19:12)
> Hi,
> 
> For a long time we have been maintaining multilib-enabled gcc package
> separately under [multilib] repo. Compilation takes a lot and usually it
> falls behind because I forget to keep it in sync with [core].
> 
> I propose to merge it with core/gcc instead and split lib32-gcc-libs.
> The latter would be moved to [core] due to dbscripts inability to
> maintain split packages in multiple repositories. On the same note, the
> same would happen to lib32-glibc.
> 
> Any objections?
> Bartłomiej

I'm definitely in favour of it, and have had some issues quite a few 
times with automatic package building and having pacman automatically 
replace gcc with gcc-multilib.

To work around it with the new reproducibility builds that are currently 
running we chose to work around it by just explicitly specifying all of 
the multilib-devel packages and then piping `yes` into pacman.

(Side note:  It would be nice if there was a handy way to say yes to all 
group members programmatically and also accepting any replaces.  Since 
the two prompts requires different input, it would currently require 
some hacky `echo` sequences into pacman, hm.)

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


signature.asc
Description: signature


Re: [arch-dev-public] Switching the bugtracker to Bugzilla

2017-11-14 Thread Johannes Löthberg via arch-dev-public
Quoting Jelle van der Waa (2017-11-14 20:30:21)
> There are several options for migrating the bug history to Bugzilla and a few 
> options are under
> debate. (input welcome)
> 
> * No migration at all
> * Migrate open bugs
> * Migrate open bugs and auto-closing them
> * Migrate all bugs
> * Migrate all bugs and auto-closing them
> 
> In either case, I believe it would be nice to "archive" the current 
> bugtracker and make it read
> only.
> 

My first reaction is that it'd be nice to not have a bunch of old cruft 
around, but if we autoclose them and we could get the migrated bugs to 
have the same ID it would simplify having the old links still work with 
just a simple redirect to the new URL with the same ID, and it would 
mean that we wouldn't need to keep the current bugtracker around for the 
indefinite future.

> # Products
> 
> * Arch packages (core/extra or split this up)
> * Community packages (community)
> * Pacman
> * AURWeb
> * Keyring
> * Archweb (new)
> * Arch VM / Docker images (new)
> * Release engineering
> 

I feel like having core and extra as separate products would make 
searching and filling in the component field a *lot* easier, because 
that's pretty much my biggest annoyance with e.g. the GNOME bugzilla, 
their component lists are huge and it's really hard to browse through 
them.

-- 
Sincerely,
  Johannes Löthberg
  PGP Key ID: 0x50FB9B273A9D0BB5
  PGP Key FP: 5134 EF9E AF65 F95B 6BB1  608E 50FB 9B27 3A9D 0BB5
  https://theos.kyriasis.com/~kyrias/


signature.asc
Description: signature


Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

2017-06-07 Thread Johannes Löthberg via arch-dev-public
Hey,

Quoting Baptiste Jonglez (2017-06-06 22:58:01)
> Hi again,
> 
> Since a few years, I maintain a variant of the linux kernel in the AUR [1]
> that adds support for Multipath TCP [2].  The most recent version is based
> on linux 4.4, and the package I maintain tries to follow the "linux"
> package from [core] as much as possible.
> 
> There is no short- or medium-term perspective to merge Multipath TCP
> upstream, so I would like to bring this package to [community].  There are
> already several kernel variants in the official repos, but I would like to
> get some feedback before adding another one.
> 
> Thanks,
> Baptiste
> 
> [1] https://aur.archlinux.org/packages/linux-mptcp/
> [2] http://www.multipath-tcp.org/

Personally I don't really think that having it in [community] would add 
that much, since it doesn't really seem to have /that/ many users 
compared to the other kernels.  Now I'm not saying that you shouldn't 
add it, just that I'm not sure how useful of an addition it would be.


Re: [arch-dev-public] todo list for moving http -> https sources

2016-11-01 Thread Johannes Löthberg via arch-dev-public

On 01/11, Sébastien Luttringer wrote:

On Sun, 2016-10-30 at 22:47 -0400, Dave Reisner wrote:

On Mon, Oct 31, 2016 at 03:23:48AM +0100, Sébastien Luttringer wrote:
> On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote:
> As I use a transparent http cache at home (2Mb/s bandwidth), so far I only
> added the signature, and not the https as it breaks the cache.

This doesn't seem to hold much weight. You're duplicating the source
tarball now, as it exists (on disk?) in your http cache and in makepkg's
SRCDEST. I'm not sure I see the benefit to doing this, particularly
since the caching in SRCDEST is entirely agnostic to the protocol used
to fetch it.


Over the time, I found a problem using $SRCDEST; it doesn't check if upstream
sources have been modified since. I've been tricked few times, releasing
packages with my local tarballs and not the one available to others.
Maybe it's something which can be improved directly in makepkg.



Mmm, it probably should check if it's been modified, and if so, complain 
loudly.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature


[arch-dev-public] Installation Guide/BG merger

2016-07-05 Thread Johannes Löthberg via arch-dev-public

Hey all,

Message from Alad, one of our dear Wiki administrators:


Historically there's been two installation guides for Arch, the 
Installation Guide [1], provided on archiso as install.txt, and the 
Beginners' Guide [2] as a more explanative guide compiled by the 
community.


There have been efforts in merging both guides since 2012 [3], but this 
only gained traction recently. [4] The plan is to merge both guides on 
the wiki "clean-up" day this Friday [5]


If you have any suggestions, also regarding if the merged guide will be 
editable by users [6], please add them to the talk page.


[1] https://wiki.archlinux.org/index.php/Installation_guide
[2] https://wiki.archlinux.org/index.php/Beginners%27_guide
[3] 
https://wiki.archlinux.org/index.php/Talk:Beginners%27_guide#A_single.2C_unified_official_install_guide
[4] https://wiki.archlinux.org/index.php/Talk:Beginners%27_guide#The_Great_Merge
[5] https://bbs.archlinux.org/viewtopic.php?id=214373
[6] https://wiki.archlinux.org/index.php/Talk:Beginners%27_guide#Page_protection

--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature


Re: [arch-dev-public] signoffs are dead

2016-07-02 Thread Johannes Löthberg via arch-dev-public

On 01/07, Florian Pritz via arch-dev-public wrote:

Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public:

That has actually come up on IRC a lot of times over the last couple
years, users asking how to sign-off packages / if they can help
signing-off.


I've already got 4 people willing to help, but nobody here voiced an 
opinion on this matter yet. Do we want such tester from a dev/TU 
perspective?




Just to state it outright, I'm very much in favour of the idea.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature


Re: [arch-dev-public] signoffs are dead

2016-06-30 Thread Johannes Löthberg via arch-dev-public

On 29/06, Florian Pritz via arch-dev-public wrote:

Am 2016-06-29 20:49, schrieb Bartłomiej Piotrowski:

I guess we can just
move to lazy consensus mode and assume if nobody complains, the package
is fine and move it after 48-76 hours.


As pointed out on arch-general (not by me) this makes the whole 
signoff process useless. Maybe we should look into finding some people 
that want to help test stuff and give them permissions to sign off on 
packages?




That has actually come up on IRC a lot of times over the last couple 
years, users asking how to sign-off packages / if they can help 
signing-off.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature