[2017-12-18 10:54:37 +0100] Bartłomiej Piotrowski via arch-dev-public:
> - tclap:
> bisson: hugin
I've just orphaned hugin too. Happy adopting! :)
--
Gaetan
[2017-12-18 22:20:02 +0100] Bruno Pagani via arch-dev-public:
> I’m taking it too. ;) But I can’t take tclap since it’s in extra, though
> this could be easily moved to [community] since hugin is the only
> package depending on it.
It's just moved. Enjoy!
(Note: I just did a rebuild because extra
[2018-01-29 16:51:54 +0100] Florian Pritz via arch-dev-public:
> Eli offered to take the lead on getting that done and also later
> migrating us to git instead of svn. If there are no objections I'll help
> where necessary and give him access to the dbscripts and devtools repos
> in two weeks.
Tha
[2018-01-29 22:00:28 +0100] Christian Rebischke via arch-dev-public:
> They even implemented a subsystem on Windows 10 for executing natively
> ELF binaries on Windows. This system is based on docker images and some
> nice guys from Microsoft have asked Allan and me if Arch Linux would be
> interes
[2018-04-19 21:19:43 +0200] Florian Pritz via arch-dev-public:
> Some feedback on how people use soyuz would probably help a lot here.
> What are your build times, how quickly do you want the result, do you
> need to see live output, does the latency to the machine matter
> (interactive usage?), ..
[2018-06-29 10:09:21 +0200] Bartłomiej Piotrowski via arch-dev-public:
> I want to enable mandatory two-factor authentication in our GitHub
> organization. Few of you unfortunately don't use it and will be
> effectively removed when I flip the switch, which I plan to do next
> week, 6th July.
No w
[2018-07-27 15:43:22 +0200] Antonio Rojas via arch-dev-public:
> Vacation time. Will be intermittently available via email/irc but won't do
> any packaging.
Same here though I might sporadically get some packaging done. Will be
back full time from Sept 1 on. Cheers.
--
Gaetan
[2018-08-24 11:51:30 +0200] Bruno Pagani via arch-dev-public:
> > scribus
>
> The develop branch (1.5.x), available as scribus-devel in the AUR (and
> maintained by myself), is Qt5. It has been in development for the past 3
> years already, and still no ETA AFAIK… I’ve been using it instead of
> s
[2018-08-24 18:45:33 +0200] Bruno Pagani:
> I have a ready PKGBUILD
> (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel)
> that I can push (after changing the pkgname) if scribus is moved to
> [community]. And we can co-maintain it there, co-maintaining is the new
> sexy. ;)
I
[2018-08-29 20:20:29 +0200] Morten Linderud via arch-dev-public:
> The rewrites have been up for a few months now and I intend to merge them
> soon.
> Feel free to still review them, either with a reply on the ML or on IRC.
> Whatever
> you prefer :)
Sorry but I don't recall such a thing ever be
[2018-08-29 18:42:39 -0400] Eli Schwartz via arch-dev-public:
> On 8/29/18 6:35 PM, Gaetan Bisson via arch-dev-public wrote:
> > [2018-08-29 20:20:29 +0200] Morten Linderud via arch-dev-public:
> >> The rewrites have been up for a few months now and I intend to merge them
&g
[2018-09-04 14:46:15 +0200] Bruno Pagani:
> Le 25/08/2018 à 01:31, Gaetan Bisson a écrit :
> > [2018-08-24 18:45:33 +0200] Bruno Pagani:
> >> I have a ready PKGBUILD
> >> (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel)
> >> that I can push (after changing the pkgname) if scr
[2018-11-06 12:13:54 +0100] Bruno Pagani via arch-dev-public:
> Le 06/11/2018 à 11:37, Allan McRae a écrit :
> > But because you asked my opinion, I think a TU council is
> > a really, really, really bad idea. No need to set some TUs above
> > others.
> Well some already are, because they are devs
[2019-01-21 18:58:54 -0500] Eli Schwartz via arch-dev-public:
> On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
> > I agree with this package list. It's missing mkinitcpio though.
>
> No it is not, mkinitcpio is definitively not needed.
>
> It's only required in order to execut
Bruno,
We all seem to agree that [base] plays no satisfactory role in its
current state, so I think Allan definitely has a point: let us first
turn [base] into something useful, and only then wonder if we need
something more.
[2019-02-05 14:38:26 +0100] Bruno Pagani via arch-dev-public:
> Le 05/
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
> Just in case it wasn’t clear, my answer would have been mostly the same
> as Eli’s.
>
> So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do
> you have further comments/questions regarding this, does the existence
> o
[2019-02-13 08:55:27 +1000] Allan McRae via arch-dev-public:
> On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
> > On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
> >> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
> >>> Ju
[2019-03-13 23:46:10 +0100] Morten Linderud via arch-dev-public:
> There is a *lot* of small tools people have written over the years that
> resides
> in bin/ directories which could be useful for more people. We also have
> several
> such tools on soyuz, where sogrep was added to devtools this w
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
> This is a follow-up on the last month discussion about a “minimal base
> system”.
Creating a new thread removed from the discussion we had a month ago
just makes it so much harder for all of us to remember what everyone's
arguments an
[2019-03-17 23:29:12 +0100] Bruno Pagani via arch-dev-public:
> I was satisfied with the consensus we reached, but when I asked on IRC
> how I should revive the thread so that we move on with that proposal to
> an actual implementation, I faced concerns about this proposal from
> several persons.
[2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public:
> Assuming we implement this group or meta-package as something of policy, i.e.
> every repository package is assumed to depend on it. This would then make
> base similar to base-devel, except for depends() instead of makedepends().
>
[2019-03-17 13:35:55 -1000] Gaetan Bisson:
> Only 156 packages have glibc in their depends array.
My bad. It's 624 packages for a total of 10.000.
Cheers.
--
Gaetan
signature.asc
Description: PGP signature
[2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public:
> I asked Bruno to start another round as previous thread is way too long
> for people who missed the party to catch up.
So some of us have taken the time to discuss this issue just a month ago
but because it's too much to read
[2019-03-25 00:46:15 +0100] Morten Linderud via arch-dev-public:
> On Sun, Mar 24, 2019 at 04:39:54PM -0700, Andrew Gregory via arch-dev-public
> wrote:
> > I don't consider hoping that libarchive doesn't need a rebuild in the
> > near future a great strategy. That being said, this is really
> >
[2019-03-27 17:19:34 +0100] Antonio Rojas via arch-dev-public:
> geeqie
I've adopted that one. Cheers.
--
Gaetan
[2019-03-27 18:08:02 +0100] Christian Rebischke via arch-dev-public:
> I would adopt:
> ttf-baekmuk
> ttf-hannom
> ttf-khmer
> ttf-sazanami
> ttf-tibetan-machine
I've just moved those to [community] for the greater good! Enjoy.
--
Gaetan
signature.asc
Description: PGP signature
Hi Christian,
[2019-06-02 01:08:30 +0200] Christian Rebischke via arch-dev-public:
> inspired by the last thread about moving proprietary software to
> community, our general problem of getting more people involved in Arch
> Linux and the (for me) chaotic organisation structure and hierarchy I
> w
[2019-06-02 06:06:35 +0200] Christian Rebischke:
> On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux
> development wrote:
> Thanks for your mail. I remember now that you have told me this some
> months ago. This leads to a question: Why are these types of dicussions
> no
[2019-06-07 09:54:25 +0200] Laurent Carlier via arch-dev-public:
> For holidays
Me too! I'll be travelling for business and pleasure from today until
July 24. Though I should remain reachable by email, my response latency
will probably increase and might reach 48h or so.
So feel free to do anythi
[2019-08-06 19:21:11 +0200] Jürgen Hötzel:
> Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08.
>
> But some well known packages depend on this preprocessor. E.g. :Haxe,
> lablgtk2 (therefore also: Unison and Coq).
>
> I don't see that these projects will be migrated to camlp5
[2019-12-12 13:21:42 +0100] Christian Rebischke via arch-dev-public:
> 1. find a consensus on rules which packages we allow in our repositories
> and which don't.
There's no need for hard rules except "don't put stuff in the repos that
will cause legal problems". We certainly strive to ship stable
[2020-01-05 21:27:19 -0300] Giancarlo Razzolini via arch-dev-public:
> Em janeiro 5, 2020 21:04 Allan McRae via arch-dev-public escreveu:
> >
> > Do we really need to write down everything? Have we reached a point in
> > the distro where common sense has stopped? Why would an announcement
> > th
[2020-01-06 16:48:48 -0300] Giancarlo Razzolini:
> I'm moving this to staff@, please stop replying on a-d-p. Doing dirty laundry
> in public is not necessary.
And I'm moving this back to arch-dev-public because most staff aren't
concerned with posting news items. Besides, there's nothing secret ab
[2020-01-06 23:11:57 +0100] Sven-Hendrik Haase via arch-dev-public:
> Every news post needs to have a corresponding draft submitted to
> arch-dev-public and wait for feedback for at least 24 hours unless:
> 1. it is urgent (and would be too late after 24 hours)
> 2. it is a simple --overwri
Dear all,
I'd like to post the following news item within the hour.
Title: sshd needs restarting after upgrading to openssh-8.2p1
Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will
be unable to accept new connections. When upgrading remote
hosts, ple
[2020-02-16 19:51:19 -0500] Eli Schwartz via arch-dev-public:
> On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
> > Dear all,
> >
> > I'd like to post the following news item within the hour.
> >
> >
> >
> > Title: sshd
[2020-02-16 19:53:53 -0500] Santiago Torres-Arias via arch-dev-public:
> On Sun, Feb 16, 2020 at 07:51:19PM -0500, Eli Schwartz via arch-dev-public
> wrote:
> > On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
> > > Dear all,
> > >
> > > I
[2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public:
> It's pretty plausible that this commit is simply incompatible with the
> previous version of sshd, therefore it could not reexec:
> https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac549e6ba89013abaf
>
> So thi
[2020-03-29 16:25:48 +0100] Filipe Laíns via arch-dev-public:
> What I would for us to do is to create a x86-64-axv2, etc. that would
> complement x86-64. We would not add it as a target for all packages,
> just for the ones that make sense.
>
> For this pacman would have to support architecture p
[2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public:
> 1) Rename libuhd to uhd
> 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks
Your proposed changes indeed seem the correct thing to do, but Kyle
appears to have done a good job maintaining those packages over the
years.
[2020-06-05 15:30:54 +0100] Filipe Laíns via arch-dev-public:
> No consensus came from my attempt at
> contacting him. And there was no discussion, it was one sided, so I
> feel like this issue is not resolved. There are still relevant points
> that I want to see addressed.
It looks to me like Kyl
Hi Jelle,
[2020-06-25 23:36:15 +0200] Jelle van der Waa:
> repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now
> on a new server which has plenty of diskspace for us to continue
> packaging for a while (16T free).
On the old host I had a systemd user service to populate this:
[2020-06-26 10:37:44 +0200] Jelle van der Waa:
> On 26/06/2020 02:50, Gaetan Bisson via arch-dev-public wrote:
> > Hi Jelle,
> >
> > [2020-06-25 23:36:15 +0200] Jelle van der Waa:
> >> repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now
> >&
[2020-07-25 00:18:55 +0200] Baptiste Jonglez:
> On 24-07-20, Giancarlo Razzolini via arch-dev-public wrote:
> > The migration is almost done. Since we are moving to a new machine, it will
> > have new host keys. They are:
> >
> >Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4
> >
[2020-07-27 21:10:23 -0300] Giancarlo Razzolini:
> Em julho 27, 2020 21:03 Gaetan Bisson escreveu:
> >
> > It's quite unsettling that we seem to be rushing to write a news post
> > while this very reasonable suggestion remains completely ignored.
> >
>
> It wasn't ignored. They keys were deliber
[2020-07-28 13:46:23 +0100] Filipe Laíns:
> If one machine gets compromised the keys are also compromised.
I never suggested to use the same keys for multiple servers.
Only that if luna's main purpose is to provide a service and this
service is moved to a different host, it makes sense to move th
Dear all,
I've joined the Arch team in 2010 and spent a decade as a developer;
it's been a great privilege to be a part of such an awesome community
and also a lot of fun. However I felt the ten-year mark was a good
opportunity for me to move on since I recognize the majority's views on
the future
[2020-08-19 20:59:13 -0400] Daniel M. Capella:
> On August 19, 2020 6:43:14 PM EDT, Gaetan Bisson via arch-dev-public
> wrote:
> > Dear all,
> >
> > I've joined the Arch team in 2010 and spent a decade as a developer;
> > it's been a great privilege t
48 matches
Mail list logo