[arch-dev-public] Python 3.9 enters the testing repos

We'll probably want to keep it in testing for a week or two. Please don't add new Python packages during this time. Many thanks to everyone who helped with the build failures. 殺

Re: [arch-dev-public] Python 3.9 rebuilds

On Sun, 15 Nov 2020 at 10:56, wrote: > > I see you have added kodi in this list. Currently python 3 is still > out-of-scope here. Until there is an official release that requires > python 3, kodi will be built against its python 2 dependencies. Indeed, kodi was included by mistake (also: dia,

[arch-dev-public] Python 3.9 rebuilds

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.9. Please avoid adding new Python packages and starting other rebuilds during this time. Some PKGBUILDs were modified in /trunk to use the Python 3.9 site-packages path (among other tweaks). Building those against Python

Re: [arch-dev-public] Packages added to todo list 'Remove libjpeg from depends/makedepends/optdepends and use shared object dependency'

David, following the concerns raised on IRC [1], is this todo getting canceled? [1] no prior discussion, library with stable soname, prioritization and scalability of adding sodeps to more packages

Re: [arch-dev-public] Pam lockout

On Fri, 11 Sep 2020 at 17:33, Tobias Powalowski via arch-dev-public wrote: > > Hi, > the 3 attempts are default. It is not overridden in the config. It was just > a transition to the new module. tally2 used to be in system-login, whereas faillock is part of system-auth. sudo includes the latter

Re: [arch-dev-public] Pam lockout

On Fri, 11 Sep 2020 at 17:05, Giancarlo Razzolini via arch-dev-public wrote: > I third you and Levente's opinion. This is a sane upstream default and should > be handled by users, if they wish to. We shouldn't deviate from upstream in > this > case. It's not an upstream default though. It's

Re: [arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs

On Wed, 26 Aug 2020 at 01:11, Eli Schwartz via arch-dev-public wrote: > The information cannot be replaced and is not redundant. But it might be > that no one actually cares about the information. On the other hand, is > it bothersome to have it there anyway? All right, I'm withdrawing my

[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs

I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after

Re: [arch-dev-public] [PATCH 2/2] makepkg.conf: Update our default FLAGS

On Fri, 10 Jul 2020 at 21:45, Jan Alexander Steffens (heftig) via arch-dev-public wrote: > 3. -fstack-clash-protection: >Hardening of large stack allocations. Cost should be negigible. > >We need to patch clang to ignore this, like we once did for -fno-plt. Apparently, Fedora didn't

Re: [arch-dev-public] Discussion - Increasing our CPU requirements

If I see a SIGILL on my AMD Phenom II X6 1090T then Arch will have failed me.  I believe your proposal should only be discussed as co-existing optimized port(s) and even then I'm not sure it's worth the trouble. Performance-critical applications can and frequently are optimized for the running

Re: [arch-dev-public] Potential removal of Chromium in ~2 months

On 22/02/2020 14:31, Dave Reisner wrote: > We've talked about this. You're well aware that this isn't an accurate > portrayal of the situation. I'm happy to guide you (or anyone else) > through the remedy. What you're looking for is continuation of the > preferential treatment that distros have

[arch-dev-public] Potential removal of Chromium in ~2 months

Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1]

Re: [arch-dev-public] libx11/xorgproto dependency

On Sat, 21 Dec 2019 at 18:13, Jan Alexander Steffens via arch-dev-public wrote: > > We now have many packages that want libx11 but say nothing about *proto, > yet they now need xorgproto as a makedepend. > Even worse, this extends further downstream, and packages building against > GTK now also

Re: [arch-dev-public] libx11/xorgproto dependency

Downstream consumers of libx11 shouldn't have to know and account for libx11's headers/pkg-config files referencing xorgproto. A libx11-devel package would depend on xorgproto. Since there's no separate -devel package, the dependency stays with the regular libx11 package. You already called (a)

Re: [arch-dev-public] Python 3.8 rebuilds

On Fri, 25 Oct 2019 at 14:34, Evangelos Foutras wrote: > > For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. > > Please avoid adding new Python packages and starting other rebuilds > during this time. Quick update: The rebuild is taking longer than e

[arch-dev-public] Python 3.8 rebuilds

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. Please avoid adding new Python packages and starting other rebuilds during this time.

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine

On Tue, 13 Aug 2019 at 18:50, Eli Schwartz via arch-dev-public < arch-dev-public@archlinux.org> wrote: > On August 13, 2019 3:03:59 AM EDT, "Bartłomiej Piotrowski via > arch-dev-public" wrote: > > I'd go with updating all packages to ship the converted files. > > Cluttering /usr with untracked

Re: [arch-dev-public] GCC 9 removed from [testing]

On Sun, 26 May 2019 at 19:51, Bartłomiej Piotrowski via arch-dev-public wrote: > You will have to -Syuu your systems. Also remember to recreate your testing and staging chroots!

Re: [arch-dev-public] Spring cleaning (take 2)

On Thu, 28 Mar 2019 at 10:04, yan12125--- via arch-dev-public wrote: > > ttf-arphic-ukai > > ttf-arphic-uming > > Hi, > > These two fonts are still useful to me. Could anyone move them to > [community]? Moved. :)

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Mon, 25 Mar 2019 at 02:47, Robin Broda via arch-dev-public wrote: > What's unclear to me is the difference between zstd -T0 and zstdmt, however. zstdmt is an alias/shortcut for "zstd -T0". > I do think that at -19+, memory usage becomes a bigger issue. > The difference between -18 and -19 on

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Mon, 25 Mar 2019 at 01:22, Jan Alexander Steffens via arch-dev-public wrote: > > On Sun, Mar 24, 2019 at 7:35 PM Robin Broda via arch-dev-public > wrote: > > The required changeset is, i think: > > PKGEXT='.pkg.tar.zst' > > COMPRESSZST=(zstd -c -T0 -18 -) > > When we implement this, I would

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Sun, 24 Mar 2019 at 23:45, Allan McRae via arch-dev-public wrote: > > On 25/3/19 4:34 am, Robin Broda via arch-dev-public wrote: > > This change requires a new pacman release, as as of writing this, zstd > > support is in master but hasn't landed in a release yet. > > Which is a complete

[arch-dev-public] Ongoing rebuilds; keep [staging] clear

The following rebuilds will be taking place in the following days: - readline - mariadb - boost - exiv2 - libidn2 - poppler Please avoid starting any new rebuilds until these are done.

Re: [arch-dev-public] Replacing pycrypto with pycryptodome

On 27 August 2018 at 22:19, Evangelos Foutras wrote: > Unless someone objects in the next few days, I'll proceed to drop > python-crypto and add replaces=() to python-pycryptodome. This has now been implemented.

[arch-dev-public] Replacing pycrypto with pycryptodome

Antonio suggested on IRC to drop pycrypto in favor of pycryptodome. The latter is "an almost drop-in replacement for the old PyCrypto library" according to its documentation. pycrypto has been unmaintained for several years. [1] Unless someone objects in the next few days, I'll proceed to drop

Re: [arch-dev-public] Caution when moving packages built against glibc 2.27

On 13 April 2018 at 18:17, Evangelos Foutras <evange...@foutrelis.com> wrote: > Care should be taken when building against glibc 2.27 (which is currently > in [staging]). > > In particular: > >- While glibc 2.27 is in [staging], new rebuilds should not be started.

[arch-dev-public] Caution when moving packages built against glibc 2.27

Care should be taken when building against glibc 2.27 (which is currently in [staging]). In particular: - While glibc 2.27 is in [staging], new rebuilds should not be started. - After glibc 2.27 migrates to [testing], packages built against it should remain in [testing] until glibc 2.27

Re: [arch-dev-public] New build server in Singapore

On 24 March 2018 at 21:33, Bartłomiej Piotrowski via arch-dev-public < arch-dev-public@archlinux.org> wrote: > For the record, the build server lives on at sgp.mirror.pkgbuild.com. > Thanks for taking care of it. I updated the sgp.pkgbuild.com record to point to the same box.

Re: [arch-dev-public] LLVM 6.0 rebuild

On 16/03/18 17:29, Anatol Pomozov via arch-dev-public wrote: > This LLVM bug is fixed in HEAD (https://reviews.llvm.org/D44140) and > should be released in 6.0.1. Or maybe we can pull it to the Arch > package? It will be included in llvm-6.0.0-4 shortly.

[arch-dev-public] LLVM 6 and splitting up {clang, lld, lldb, compiler-rt} into separate PKGBUILDs

I pushed llvm 6.0.0-1 to [staging] without the rest of the packages mentioned in the subject. I am planning to add them back as individual packages in the following days. This separation will bring faster builds when one of these components needs patching. It also allows building clang with

[arch-dev-public] Resigning as TU

For a long time I have been inactive in TU matters (i.e.: handling AUR requests, looking into TU applicants, and overseeing community contributions in general). Due to this, I feel it's proper to let go of my TU title. No heartfelt goodbyes, since my involvement in Arch remains unchanged. (On a

Re: [arch-dev-public] Changing compilation flags

On 7 July 2017 at 19:17, Jordan Glover wrote: > I'm surprised as it seemed to me that Daniel took it for granted that > patch like that will get accepted. Anyway it's hard for an outsider to > successfully submit anything to big upstream project. I hope you'll be

Re: [arch-dev-public] Changing compilation flags

On 7 July 2017 at 16:39, Jordan Glover wrote: > FYI clang devs don't want to take 1 line patch adding another no-op flag > upstream. > https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html Thanks for trying to push the change upstream. I'm sorry they

Re: [arch-dev-public] Changing compilation flags

On 5 July 2017 at 19:51, Daniel Micay <danielmi...@gmail.com> wrote: > On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote: >> On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public >> <arch-dev-public@archlinux.org> wrote: >> > Using -fno-plt wou

Re: [arch-dev-public] Changing compilation flags

On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public wrote: > Using -fno-plt would be a nice tiny little performance boost at runtime > but then it's important to make sure everything is compiled with -Wl,- > z,now and there might be programs ignoring LDFLAGS

Re: [arch-dev-public] Changing compilation flags

On 30/06/17 22:22, Jelle van der Waa wrote: > On 06/30/17 at 09:49pm, Evangelos Foutras via arch-dev-public wrote: >> On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public >> <arch-dev-public@archlinux.org> wrote: >>> It's probably a good idea to leave it i

Re: [arch-dev-public] Changing compilation flags

On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public wrote: > It's probably a good idea to leave it in CFLAGS for Clang. I am planning to patch Clang to follow GCC's behavior similarly to what Alpine does. [1] We can discuss dropping the related compilation

[arch-dev-public] Perl 5.26 rebuild in progress

A quick heads-up: we are in the process of pushing rebuilds for Perl 5.26 to [staging]. Please avoid starting other rebuilds until this is completed, to avoid possible overlap with the Perl rebuild. Some build or test failures are expected due to Perl 5.26's removal of the current directory from

Re: [arch-dev-public] icu/poppler/hunspell rebuilds moved back to staging repos

On 29/11/16 07:15, Evangelos Foutras wrote: > After moving the [icu 58.1 / poppler 0.49.0 / hunspell 1.5.0] rebuilds > from staging to testing, I noticed that Firefox would now immediately > throw a segmentation fault at startup. Due to this breakage, I quickly > moved the packages bac

[arch-dev-public] icu/poppler/hunspell rebuilds moved back to staging repos

After moving the [icu 58.1 / poppler 0.49.0 / hunspell 1.5.0] rebuilds from staging to testing, I noticed that Firefox would now immediately throw a segmentation fault at startup. Due to this breakage, I quickly moved the packages back to staging until this is resolved. Anyone who upgraded during

Re: [arch-dev-public] Clang 3.8 Package?

On Apr 15, 2016 1:06 AM, "Thomas Kowaliczek" <thomas.kowalic...@posteo.de> wrote: > > Hello Evangelos Foutras my name is Thomas Kowaliczek and i wanted to ask give it an timeline when we will see llvm/clang 3.8 in arch linux? > > > Greetings > > Thomas Kowal

[arch-dev-public] Away for (mandatory) military service of 8 months starting March 9th

During the first ~3 weeks of basic training, I will be completely unreachable without access to my email. After that, I'll be home for 4-5 days before transferring to another unit/camp for several months. (I might be able to sneak in a laptop or netbook at some point after basic training, but

Re: [arch-dev-public] PHP 7

On 29/12/15 22:23, Pierre Schmitz wrote: > On 29.12.2015 20:12, Pierre Schmitz wrote: >> php-memcached > > There was a php7 branch which I pushed into [community-staging] I did the same for php-memcache. :^)

Re: [arch-dev-public] PHP 7

On 29/12/15 23:49, Ike Devolder wrote: > So I would add the php-mongodb package that replaces the current > php-mongo package with an extra note that its api is not compatible. replaces=() should not be used if the new package is not compatible with the one it is replacing; a note in the PHP 7

Re: [arch-dev-public] C++ ABI rebuild announcement

On Sun, Dec 13, 2015 at 11:02 AM, Pierre Schmitz wrote: > I assume the cxx11abitest symlink can be reomved from he repos now? Sounds like something I forgot to remove back in June when I did the test rebuilds. I can't find anything with that name on nymeria; which server is

Re: [arch-dev-public] C++ ABI rebuild announcement

On Sun, Dec 13, 2015 at 11:50 AM, Pierre Schmitz wrote: > It looks like it is only on at least one mirror: > > rsync://mirror.leaseweb.net/archlinux/ > > ignoring unsafe symlink "cxx11abitest" -> "/mnt/cxx11abitest/repo/" The rsync command specified in the wiki should have

Re: [arch-dev-public] C++ ABI rebuild announcement

On Thu, Dec 10, 2015 at 5:02 AM, Allan McRae wrote: > Here is a draft announcement. Please go ahead and post the announcement; I have started the move and it should complete in an hour or so. I have made a couple of comments bellow. > --BEGIN-- > C++ ABI rebuild > >

Re: [arch-dev-public] C++ ABI rebuild announcement

The move is done so I went ahead and posted the news item.

[arch-dev-public] Do not update packages that are part of the C++11 ABI change rebuilds

Reposting this with the main point in the title since some updates made their way into [community]; see Allan's message for details. [1] Doing minor version bumps in [staging]/[community-staging] is fine, however, the repo hierarchy needs to maintain monotonic versioning (can't have newer

Re: [arch-dev-public] On pushing a standalone opencv 3.x

On Sat, Dec 5, 2015 at 11:57 AM, Bartłomiej Piotrowski wrote: > We can handle this rebuild with Evangelos' arch-rebuild script. Only if it is a simple pkgrel bump; the discussed rebuild seems to require packages switching over to a new opencv2 package, in which case it

Re: [arch-dev-public] Do NOT install glibc-2.22-4

On Mon, Oct 12, 2015 at 5:07 AM, Allan McRae wrote: > allanbrokeit > > > It installed fine here, then everything slowly died! I had to find > another system with a ssh key to remove it from the repos so it seems to > have propagated in that time. > > A Sounds like I missed

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

On Sat, Sep 19, 2015 at 1:45 PM, Anatol Pomozov wrote: > python35 rebuild with 500+ packages. To finish this rebuild requires a lot > of time from developers. I wonder if your magic tool can be utilized again. We went with a todo list for this rebuild because some

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

On Fri, Sep 11, 2015 at 12:14 AM, Evangelos Foutras <evange...@foutrelis.com> wrote: > 1) TeXLive 2015 is currently in [testing] but only texlive-bin is part > of the rebuilds. Therefore, we must wait until TeXLive 2015 leaves > [testing] before moving the ncurses stuff out of th

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

On 06/09/15 20:02, Evangelos Foutras wrote: > You can follow the progress at: https://rebuilds.foutrelis.com/ > > If anyone wants to tackle a build failure, you can commit the fix in > /trunk (without bumping pkgrel) and then click on the failing package > and select "Retry bu

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

On 07/09/15 16:30, Christian Hesse wrote: > Evangelos Foutras <evange...@foutrelis.com> on Sun, 2015/09/06 20:02: >> You can follow the progress at: https://rebuilds.foutrelis.com/ >> >> If anyone wants to tackle a build failure, you can commit the fix in >&g

[arch-dev-public] Automated rebuild for ncurses 6.0 in progress

You can follow the progress at: https://rebuilds.foutrelis.com/ If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task". Note: This rebuild is not listed on

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

On 06/09/15 21:18, Pierre Schmitz wrote: > On 06.09.2015 19:02, Evangelos Foutras wrote: >> You can follow the progress at: https://rebuilds.foutrelis.com/ >> >> If anyone wants to tackle a build failure, you can commit the fix in >> /trunk (without bumping pkgrel) an

Re: [arch-dev-public] C++ ABI change rebuild

On a relevant note, today I tested some experimental packages built with the new C++11 ABI. [1] Judging by this test run, we should be able to do the rebuilds, in a mostly automated way, within about 3 days once we decide to implement the ABI change. [2] My regular Xfce desktop seemed to work

Re: [arch-dev-public] C++ ABI change rebuild

On 29/06/15 10:21, Evangelos Foutras wrote: My regular Xfce desktop seemed to work fine (incl. Firefox and Chromium). I also tried KDE's Plasma desktop with no issues. Forgot to mention that the ABI change breaks Skype; this was expected since it uses the system Qt4. As is the case with closed

Re: [arch-dev-public] C++ ABI change rebuild

On 29/06/15 10:21, Evangelos Foutras wrote: I did, however, see two crashes listed in coredumpctl but I didn't notice them during normal usage, probably because they happened at program termination. [3] Scratch that... they also occur with the regular packages (on session logout most likely

[arch-dev-public] Package removal: yap

I removed yap from [community] as it's unmaintained (both upstream and in Arch) and doesn't build with GCC 5.1. Though a fix exists in a mailing list post upstream, I encountered further issues with its Java bindings and building its texinfo documentation. If anyone wants to put it back in

Re: [arch-dev-public] C++ ABI change rebuild

On 02/06/15 15:01, Allan McRae wrote: We will start the rebuild for the C++ ABI change [1] as soon as the perl rebuild is out of staging. Do not start any other rebuild in the meantime (unless it is small and you can finish it immediately). This rebuild will be much smoother if everyone

Re: [arch-dev-public] PGP key update

On Fri, Jun 5, 2015 at 7:42 AM, Pierre Schmitz pie...@archlinux.de wrote: there is a new keyring package in testing. Can we move this to [core]? The old signature expired today.

[arch-dev-public] Data corruption on software RAID 0 w/ discard option set

Holger Kiehl describes the issue pretty well here: https://lkml.org/lkml/2015/5/21/167 I included the proposed fix in linux 4.0.4-2 and linux-lts 3.14.43-2; these kernels are currently in [testing] but we should move them to [core] as soon as possible so please provide a couple more signoffs.

[arch-dev-public] Package removal: fatrat

I've removed fatrat from [community]; there is no upstream activity and it has been holding back the libtorrent-rasterbar update to 1.0.x for a while now. The download links are also broken at the moment (I don't know if this is a temporary issue or not), so I've decided not to upload it to the

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 22/04/15 04:33, Evangelos Foutras wrote: On 22/04/15 04:08, Allan McRae wrote: On 22/04/15 10:58, Evangelos Foutras wrote: I feel a stronger case would need to be made for moving vim-minimal to [core]. At the moment we're only trying to figure out a sane fallback editor, mostly for visudo

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 22/04/15 01:05, Jan Alexander Steffens wrote: On Wed, Apr 22, 2015 at 12:03 AM, Evangelos Foutras evange...@foutrelis.com wrote: On 22/04/15 00:49, Allan McRae wrote: I think the symlink is very important. And I am very against VIsudo calling anything other than vi by default. Unless you

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 21/04/15 23:45, Jerome Leclanche wrote: As long as the EDITOR variable is supported by those programs, maybe yes. But I don't think creating a symlink *anyway* and make vim provide vi is inappropriate. Yes, the VISUAL/EDITOR environment variables should still be honored by these

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 21/04/15 16:27, Allan McRae wrote: What happened to adding a symlink? Now there is no vi in base, many packages there are broken out of the box - sudo (visudo), bash (bashbug), less (when pressing v). There is bound to be more... Or are we having all those packages depend on vim?

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 22/04/15 01:30, Evangelos Foutras wrote: On 22/04/15 01:05, Jan Alexander Steffens wrote: On Wed, Apr 22, 2015 at 12:03 AM, Evangelos Foutras evange...@foutrelis.com wrote: On 22/04/15 00:49, Allan McRae wrote: I think the symlink is very important. And I am very against VIsudo calling

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 22/04/15 04:08, Allan McRae wrote: On 22/04/15 10:58, Evangelos Foutras wrote: I feel a stronger case would need to be made for moving vim-minimal to [core]. At the moment we're only trying to figure out a sane fallback editor, mostly for visudo and I guess cronie's crontab. nano seems

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 22/04/15 02:57, Allan McRae wrote: On 22/04/15 08:55, Evangelos Foutras wrote: By the way, it's worth noting that vim-minimal has a footprint of about 30 MiB. It's not much, but compared to nano's 2 MiB, it's way larger. I'm probably repeating what I've written in my previous posts

Re: [arch-dev-public] Incorrect patches for GnuTLS 3.4.0

On 16/04/15 16:55, Sergej Pupykin wrote: On Thu, 16 Apr 2015 16:41:07 +0300, Evangelos Foutras evange...@foutrelis.com wrote: Hi Sergej, The GnuTLS patches you added to a few packages today appear to be incorrect. gnutls_priority_set_direct() is not a direct replacement

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

On 29/03/15 18:15, Evangelos Foutras wrote: This was discussed about two years ago but no action was taken. The proposal is simple: - Drop the vi package from the repos - Add vim-minimal to the installation image This seems like a good idea because the vi editor we ship is about 10

[arch-dev-public] Dropping vi and adding vim-minimal to the installation image

This was discussed about two years ago but no action was taken. The proposal is simple: - Drop the vi package from the repos - Add vim-minimal to the installation image This seems like a good idea because the vi editor we ship is about 10 years old and it has never behaved correctly for me. It

[arch-dev-public] Dropping frostwire

Beginning with Frostwire 6.0.0, upstream has started using libtorrent via custom Java bindings (jlibtorrent) so the package is no longer architecture independent and is officially only targeted at x86_64. My main concern is that the source for libjlibtorrent.so is only provided in the form of a

[arch-dev-public] Dropping mplayer-vaapi

I feel that this package is no longer needed and I've personally switched to using mpv with smplayer for VAAPI support. I'll be moving mplayer-vaapi to the AUR in a few days.

Re: [arch-dev-public] linux 3.19 in [testing]

Just did virtualbox-modules (and bbswitch which was missing from [community-testing]).

Re: [arch-dev-public] user/group management in packages

On 03/02/15 17:58, Andrew Gregory wrote: -1 for systemd-sysusers unless you can figure out a way to use it in pre_install. In order for the dynamic user creation Allan mentioned to work, pacman will have to be changed to use symbolic user names for file ownership which requires the user to

Re: [arch-dev-public] user/group management in packages

On 03/02/15 13:46, Allan McRae wrote: Hi all, While looking into how best handle those directory permission warnings with pacman-4.2, I have noticed a couple of things about user/group management in our packages. 1) We should not remove users/groups when packages are uninstalled. This is

[arch-dev-public] Maintainer needed for extra/brltty

Being the last packager of brltty, I've received a request to update it to 5.2. I will try to do that as it seems to be a simple version bump (and the user has offered to test the package). Long term though, the package will have to be moved to [community] or the AUR. If someone is interested in

Re: [arch-dev-public] Announcement Draft: Changes to microcode updates

On 22 October 2014 20:09, Thomas Bächler tho...@archlinux.org wrote: Changes to microcode updates Microcode on Intel CPUs is no longer loaded automatically, as it needs to be loaded very early in the boot process. This requires adjustments in the bootloader. If you have an Intel CPU, please

Re: [arch-dev-public] Changes to microcode updates

On 12/10/14 18:13, Evangelos Foutras wrote: On 12/10/14 15:28, Thomas Bächler wrote: For AMD, a similar mechanism is available, but since I don't own an AMD CPU, I cannot implement this. This causes problems, since the microcode update is no longer triggered automatically on boot (since

Re: [arch-dev-public] Changes to microcode updates

On 12/10/14 15:28, Thomas Bächler wrote: For AMD, a similar mechanism is available, but since I don't own an AMD CPU, I cannot implement this. This causes problems, since the microcode update is no longer triggered automatically on boot (since microcode is no longer a module). If you want to

Re: [arch-dev-public] [RFC] New package: vte3-2.90

On 29/09/14 19:39, j...@jgc.homeip.net wrote: I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay

Re: [arch-dev-public] linux 3.17 in [testing]

On 6 October 2014 19:38, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Only acpi_call binary module did not build. Please take a look at it. This is now fixed.

[arch-dev-public] [RFC] New package: vte3-2.90

(I would really like opinions from our GNOME maintainers on this.) Seeing as vte3 0.38.0 in [testing] has a new API, I went ahead a created a todo list to rebuild the packages that depend on the old libvte2_90 library. [1] Patches that port the affected software to the new API might not be

Re: [arch-dev-public] [RFC] New package: vte3-2.90

On 29 September 2014 06:45, Anatol Pomozov anatol.pomo...@gmail.com wrote: Are you going to remove vte-common once the migration is done? No, it's an existing package which currently only contains usr/lib/vte/gnome-pty-helper which is split off from the vte3 package. We would just also add

Re: [arch-dev-public] moving lz4 to [core]

On 28 August 2014 04:10, Dave Reisner d...@falconindy.com wrote: Hi, lz4 is growing in popularity as a compression algorithm. As of systemd 216, systemd-journald supports lz4 (in addition to xz). Benchmarks[1] were provided at the time Zbigniew wrote the patches to show the impressive drop

Re: [arch-dev-public] linux 3.16 in [testing]

On 4 August 2014 10:38, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Hi, just released 3.16 kernel to [testing] repository. Only r8168 binary module did not build. Please take a look at it. Fixed r8168. It's also worth mentioning that we no longer change the default console

Re: [arch-dev-public] Linux 3.14 in [testing]

On 03/04/14 11:10, Thomas Bächler wrote: Am 03.04.2014 05:24, schrieb Evangelos Foutras: On 2 April 2014 01:20, Thomas Bächler tho...@archlinux.org wrote: It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing]. Has anyone else experienced hangs

Re: [arch-dev-public] Linux 3.14 in [testing]

On 2 April 2014 01:20, Thomas Bächler tho...@archlinux.org wrote: It may be another short while until I run db-update, but I started pushing the 3.14 stuff to [testing]. Has anyone else experienced hangs in Firefox with the latest kernel? If I attach gdb to the firefox process it gets unstuck

Re: [arch-dev-public] [core] build status - 2013-10-24

On 24 October 2013 07:32, Allan McRae al...@archlinux.org wrote: FAILdialog Fixed.

Re: [arch-dev-public] syslinux-6.02

On 18 October 2013 13:50, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Please confirm if chainloading is fixed in 6.02-3 Yep, it does work now. Thanks.

Re: [arch-dev-public] syslinux-6.02

On 17 October 2013 07:25, Evangelos Foutras evange...@foutrelis.com wrote: On 14 October 2013 11:08, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Hi, I just release syslinux 6.02 to testing, are now all issues with archiso fixed? That we can move this to [core]? For me

Re: [arch-dev-public] syslinux-6.02

On 14 October 2013 11:08, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Hi, I just release syslinux 6.02 to testing, are now all issues with archiso fixed? That we can move this to [core]? For me, syslinux 6.02-2 fails to boot Windows 7 (located on a secondary hard drive). It

Re: [arch-dev-public] linux-3.10-1 in [staging]

On 2 July 2013 15:37, Massimiliano Torromeo massimiliano.torro...@gmail.com wrote: On Tue, Jul 2, 2013 at 7:54 AM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Please find patches and fix those. Hi, I have committed the patch for r8168 on trunk. Well, push a rebuild with the

Re: [arch-dev-public] Some PNG images won't work with libpng 1.6

On 06/05/13 09:12, Evangelos Foutras wrote: On 3 May 2013 14:36, Evangelos Foutras evange...@foutrelis.com wrote: It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images. Looks like there's probably going to be a workaround in libpng

Re: [arch-dev-public] Some PNG images won't work with libpng 1.6

On 3 May 2013 14:36, Evangelos Foutras evange...@foutrelis.com wrote: It's not clear whether future libpng 1.6.x versions will be able to load these, apparently invalid, PNG images. Looks like there's probably going to be a workaround in libpng 1.6.3: https://bugzilla.mozilla.org/show_bug.cgi

Re: [arch-dev-public] [testing] libtirpc 0.2.3-1 breaks pam_unix

On 5 May 2013 04:31, Jan Alexander Steffens jan.steff...@gmail.com wrote: libtirpc 0.2.3-1 breaks pam_unix, making login and su(do) impossible: May 05 03:22:54 philomeena login[24274]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/security/pam_unix.so: undefined symbol:

  1   2   3   4   >