[arch-dev-public] Fwd: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)

know that this will probably upset people's muscle-memory as most people probably have been using these tools for decades. I guess that's not an insurmountable problem for us though? Cheers, Tom -- Forwarded message ------ From: Tom Gundersen Date: Thu, Apr 24, 2014

Re: [arch-dev-public] providing grsecurity in [community]

On Sat, Apr 19, 2014 at 11:58 PM, Daniel Micay wrote: > On 19/04/14 05:25 PM, Tom Gundersen wrote: >> >> In short, work on grsec if you want, but please let's not use that as >> an excuse to discourage people from working on similar features for >> the main ker

Re: [arch-dev-public] providing grsecurity in [community]

On Sat, Apr 19, 2014 at 11:47 PM, Daniel Micay wrote: > On 19/04/14 05:25 PM, Tom Gundersen wrote: >> On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay wrote: >>> Users have been asking for MAC to be provided in the repositories for a >>> long time. At the moment,

Re: [arch-dev-public] providing grsecurity in [community]

On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay wrote: > Users have been asking for MAC to be provided in the repositories for a > long time. At the moment, two bugs are open about it: > > https://bugs.archlinux.org/task/37578 > https://bugs.archlinux.org/task/39852 > > Any of these reported bugs co

Re: [arch-dev-public] providing grsecurity in [community]

On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay wrote: > There has been a recent surge of interest in securing Arch by paying > closer attention to CVEs and addressing many security issues in our > packages. I also started some initial work/documenting on securing the > services shipped in various p

Re: [arch-dev-public] Drop cronie and logrotate from base?

On Tue, Apr 1, 2014 at 9:30 PM, Andrea Scarpino wrote: > On Tue 01, April 20:48:16 Florian Pritz wrote: >> Moving to extra sounds good. > > +1 As Gaetan already agreed: +1 from me too. >> Move it to extra and make it a dep of everything that logs to /var/log >> by default, optdep for stuff that

Re: [arch-dev-public] [RFC] Add ARM to archlinux.org

On Fri, Mar 28, 2014 at 1:14 AM, Andrea Scarpino wrote: > On Mon 24, March 15:02:53 Gaetan Bisson wrote: >> Personally, although I think the AUR is a valuable service and that you >> shouldn't be assuming its costs and maintenance alone, I'm not sure if >> making it official would be a good thing

Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

On Fri, Mar 28, 2014 at 3:01 AM, Gaetan Bisson wrote: > [2014-03-27 21:01:17 -0400] Daniel Micay: >> setuid binary (crontab) so it opens up a vulnerability in the base install. >> >> Among others (although one requires cron to be enabled): >> >> * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-20

Re: [arch-dev-public] 3.13 packages in testing

Hi Thomas, On Sun, Jan 26, 2014 at 7:04 PM, Thomas Bächler wrote: >> Am 26.01.2014 13:56, schrieb Tom Gundersen: > Okay, there are two problems: 1), the i8042 module was lacking > modaliases. This is resolved by this patch http://pastebin.com/bKydQZLF I'll submit this upstre

Re: [arch-dev-public] 3.13 packages in testing

On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler wrote: > One major change is coming (and Tom will be happy about it): Keyboard > support is entirely modular, even for AT(PS/2) keyboards. Beware that in > order to have keyboard input during early boot, you need the 'keyboard' > hook in mkinitcpio.

Re: [arch-dev-public] [RFC] preparing dbus for coexistence with kdbus

On Sun, Dec 1, 2013 at 7:05 PM, Tom Gundersen wrote: > Work on kdbus is nearing completion (of a first version at least) and > it will soon be submitted upstream. We will also soon have a 'bridge' > in systemd between the old libdbus and kdbus. This bridge will > conflict wi

[arch-dev-public] [HEADSUP] Arch boot splash

Hi guys, I thought I'd let you know that I just pushed a new version of gummiboot to [testing] which now has support for showing a splash-screen at boot [0]. I shipped it with the Arch Linux logo (/usr/lib/gummiboot/splash-arch.bmp), which can be copied to /boot/EFI/gummiboot/splash.bmp if you wa

Re: [arch-dev-public] [RFC] preparing dbus for coexistence with kdbus

On Mon, Dec 2, 2013 at 1:36 AM, Gerardo Exequiel Pozzi wrote: > On 12/01/2013 03:05 PM, Tom Gundersen wrote: >> Hi guys, >> >> Work on kdbus is nearing completion (of a first version at least) and >> it will soon be submitted upstream. We will also soon have a 'b

[arch-dev-public] [RFC] preparing dbus for coexistence with kdbus

Hi guys, Work on kdbus is nearing completion (of a first version at least) and it will soon be submitted upstream. We will also soon have a 'bridge' in systemd between the old libdbus and kdbus. This bridge will conflict with the old dbus daemon, but libdbus will still be around for a long time.

Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)

On Wed, Nov 27, 2013 at 2:43 PM, Alexander Rødseth wrote: > Something like: > > replaces=('docker=1.5') > > in the docker-tray PKGBUILD? > > Isn't that equally problematic, since that could cause problems if > docker (currently at version 0.7) reached version 1.5? I guess this could be simply sol

Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)

On Wed, Nov 27, 2013 at 12:49 PM, Sébastien Luttringer wrote: > On 27/11/2013 11:35, Thomas Bächler wrote: >> Am 27.11.2013 11:29, schrieb Allan McRae: >>> Please don't do this... 11 line output in post_install. If you >>> REALLY need this, use a single line pointing to the wiki page. >>> >>>

Re: [arch-dev-public] [arch-general] Dropping bluez4

On Wed, Nov 6, 2013 at 9:21 PM, Andreas Radke wrote: > I've done some work and research on bluez lately. I can confirm my > adapters to work with bluez 5.10 and gnome-bluetooth (connecting > to headset + smartphone) that has already moved to extra. > > I couldn't make it work with kde+bluedevil th

Re: [arch-dev-public] lirc kernel drivers

On Mon, Nov 4, 2013 at 5:11 PM, Tobias Powalowski wrote: > Am 14.10.2013 14:57, schrieb Tom Gundersen: >> Hi guys, >> >> As lirc package is currently an orphan, I thought I'd had a look at it >> to see if we can clean it up. >> >> Most of the lirc kern

Re: [arch-dev-public] Dropping sysvinit-tools

On Sat, Oct 26, 2013 at 6:29 PM, Dave Reisner wrote: > The next release of procps-ng will contain pidof and clash with > sysvinit-tools. The obvious decision is to use the maintained source of > pidof. At this point, we'll be left with 3 binaries in sysvinit-tools, > all which I propose are all ob

[arch-dev-public] lirc kernel drivers

Hi guys, As lirc package is currently an orphan, I thought I'd had a look at it to see if we can clean it up. Most of the lirc kernel drivers are now upstream, so we only ship three of them: *) lirc_atiusb: this overlaps with ati_remote [0] which is upstream. This is bad as it means users will

[arch-dev-public] Dropping bluez4

Hi guys, Once pulseaudio and bluedevil moves out of [testing], the only official package depending on bluez4 will be blueman. As blueman was last released two years ago, and last upstream activity was more than one year ago and that bluez4 is no longer developed upstream at all, I suggest droppin

Re: [arch-dev-public] Git

On Sun, Sep 29, 2013 at 9:48 PM, Connor Behan wrote: > On 29/09/13 12:25 PM, Alexander R?dseth wrote: >> Hi, >> >> As I gather, we all like git better than svn, for a long list of >> reasons. Are there any objections to switching over from svn to git for >> repositories for the official packages?

Re: [arch-dev-public] Git

On Sun, Sep 29, 2013 at 9:00 PM, Alexander Rødseth wrote: > As I gather, we all like git better than svn, for a long list of > reasons. Are there any objections to switching over from svn to git for > repositories for the official packages? I'm strongly in favor of git, and would be happy to work

Re: [arch-dev-public] replacing efibootmgr with efibootmgr from peter jones with libefivar support?

On Mon, Sep 9, 2013 at 3:16 PM, Tobias Powalowski wrote: > while improving archboot's uefi capabilities, Keshav which wrote most of > the UEFI documentation on wiki comes up with this wish to switch to > Peter Jones efibootmgr. > > For explanation for sysfs-efivar vs.efivarfs, efivarfs is the futu

Re: [arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools

On Tue, Aug 13, 2013 at 6:30 PM, Thomas Bächler wrote: > > Am 13.08.2013 16:06, schrieb Thomas Bächler: > > Am 13.08.2013 15:59, schrieb Tom Gundersen: > >> Hi guys, > >> > >> As you can see below, util-linux-24 will contain most of the tools > >

[arch-dev-public] [AWAY] until the end of August

Hi guys, Just letting you know that I'll be on holiday (with email, but no signing keys) until the end of this month. Feel free to do whatever is necessary to my packages. Cheers, Tom

[arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools

Hi guys, As you can see below, util-linux-24 will contain most of the tools from sysvinit-tools. I therefore intend to propose that we drop sysvinit-tools once util-linux-24 is out. If anyone have any objections or concerns, this would be the perfect time to speak up, so we can sort out any probl

Re: [arch-dev-public] The next LTS

On 6 Aug 2013 01:30, "Thomas Bächler" wrote: > We might as well keep 3.10 for another 2 years. For what it is worth, I would really prefer if we only keep each LTS until the next one is out (i.e., one year). The reason being that running new user space on an old kernel is explicitly not supported

[arch-dev-public] The next LTS

Hi, In case someone missed it, Greg just announced that 3.10 will be the next LTS kernel [0]. It might make sense to bump linux-lts to 3.10 shortly after linux-3.11 moves to [core]. What do you think? -t [0]:

Re: [arch-dev-public] Syslinux 6.0 released with efi support

On Fri, Jun 21, 2013 at 12:08 PM, Pierre Schmitz wrote: > Am 21.06.2013 11:52, schrieb Tobias Powalowski: >> Hi, >> my plan for this release will be to replace the syslinux package with >> syslinux-bios >> and package the efi part as syslinux-efi package. This will be like the >> grub packages. >

[arch-dev-public] [RFC] moving gummiboot to core

Hi, Tobias and I would like to move gummiboot from [extra] to [core]. For those who don't know, it is a very minimal boot loader for uefi systems [0], currently used on our iso. Any objections? Tom [0]:

Re: [arch-dev-public] [RFC] move libusb-compat from [core] to [extra]

On Sun, Jun 16, 2013 at 12:35 PM, Tom Gundersen wrote: > I'd like to move libusb-compat out of [core], any objections? > > No other packages in [core] depends on it, but gnupg {opt,make}depends on it. Done. -t

[arch-dev-public] [RFC] move libusb-compat from [core] to [extra]

Hi guys, I'd like to move libusb-compat out of [core], any objections? No other packages in [core] depends on it, but gnupg {opt,make}depends on it. Cheers, Tom

Re: [arch-dev-public] [RFC] Bluez 5

On Mon, May 13, 2013 at 6:02 PM, Tom Gundersen wrote: > I would like to push Bluez 5 to the repos, and rename Bluez 4 to > 'bluez4'. Some things still require Bluez 4, and the two can not be > installed together, so this is how I propose to do it. > > We will ha

Re: [arch-dev-public] [RFC] Bluez 5

On Thu, Jun 6, 2013 at 9:15 AM, Tobias Powalowski wrote: > Am 06.06.2013 07:49, schrieb Jan Alexander Steffens: >> On Thu, Jun 6, 2013 at 7:38 AM, Tobias Powalowski >> wrote: >>> Please don't move qemu with bluez move. >>> qemu 1.5.0 is a bit to buggy to leave testing repository. >>> If you move

Re: [arch-dev-public] Junior Devs

On Mon, Jun 3, 2013 at 4:48 PM, Thomas Bächler wrote: > Am 03.06.2013 16:37, schrieb Tom Gundersen: >> Hi guys, >> >> This was brought up a few times, so I'd like some clarification. >> >> What restrictions (apart from the possibility of getting the boot, an

[arch-dev-public] Junior Devs

Hi guys, This was brought up a few times, so I'd like some clarification. What restrictions (apart from the possibility of getting the boot, and no read-access to arch-dev) do we put on Junior devs? It used to be that they could not push packages, but that is no longer a technical limitation. Sho

[arch-dev-public] [FYI] New developer: Laurent Carlier

Hi all, The devs would like to welcome Laurent Carlier (lordheavy) on board as a new dev. Laurent has been a Trusted User for a number of years, and he has a consistent track-record of being easy to work with, being frequently available, and maintaining a wide range of high-quality packages, so w

Re: [arch-dev-public] New draft - Was: /usr move - update instructions

On Mon, Jun 3, 2013 at 10:57 AM, Pierre Schmitz wrote: > Am 03.06.2013 09:41, schrieb Tom Gundersen: >> On Mon, Jun 3, 2013 at 5:05 AM, Allan McRae wrote: >>> And the news draft: >> >> Looks good to me. Time to make the move? > > Fine with me. Maybe we could

Re: [arch-dev-public] New draft - Was: /usr move - update instructions

On Mon, Jun 3, 2013 at 5:05 AM, Allan McRae wrote: > And the news draft: Looks good to me. Time to make the move? -t

Re: [arch-dev-public] [RFC] Bluez 5

On Mon, May 13, 2013 at 6:02 PM, Tom Gundersen wrote: > I would like to push Bluez 5 to the repos, and rename Bluez 4 to > 'bluez4'. Some things still require Bluez 4, and the two can not be > installed together, so this is how I propose to do it. > > We will ha

Re: [arch-dev-public] [RFC] new default PATH

On Sat, Jun 1, 2013 at 1:09 AM, Gerardo Exequiel Pozzi wrote: > On 05/31/2013 04:04 PM, Tom Gundersen wrote: >> Hi guys, >> >> When updating our default PATH in /etc/profile due to the usrmerge I >> noticed it is not consistent with the system-wide PATH set

[arch-dev-public] [RFC] new default PATH

Hi guys, When updating our default PATH in /etc/profile due to the usrmerge I noticed it is not consistent with the system-wide PATH set by PID1. systemd sets: "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" which for us is equivalent to "/usr/local/sbin:/usr/local/bin:/usr/bin" but profi

Re: [arch-dev-public] Finishing the /usr move

On Fri, May 31, 2013 at 1:35 PM, Sébastien Luttringer wrote: > Why not symlink /usr/local/sbin to /usr/local/bin in filesystems? I think we should do this, but not everyone agrees. As it is independent of the current move, let's discuss it once that has finished. -t

Re: [arch-dev-public] Finishing the /usr move

On Fri, May 31, 2013 at 5:50 AM, Allan McRae wrote: > > Doing a "pacman -Syu" gave a conflict as expected. Did not test that > "pacman -Syu --force" failed, because it was on my only working system > at the moment. > > The followed the instructions above. Rebooted at the end for good > measure.

Re: [arch-dev-public] Finishing the /usr move

On Thu, May 30, 2013 at 5:35 AM, Allan McRae wrote: > On 30/05/13 06:23, Eric Bélanger wrote: >> On Tue, May 28, 2013 at 9:56 PM, Allan McRae wrote: >> >>> I'm bored of waiting... so lets do this! What a plans with regard to >>> [staging] in the near future? When it is free, I will kill the

Re: [arch-dev-public] [RFC] dropping LILO?

On Tue, May 21, 2013 at 8:41 AM, Tobias Powalowski wrote: > Am 16.05.2013 01:20, schrieb Tom Gundersen: >> Hi guys, >> >> I was just going through some of the orphans in the usrmove TODO list >> and noticed that lilo is one of them. If no one wants to adopt it, >>

Re: [arch-dev-public] Finishing the /usr move

On Wed, May 29, 2013 at 3:56 AM, Allan McRae wrote: > I'm bored of waiting... so lets do this! Please do. I suppose people can still skip staging for packages where that makes sense to minimize the congestion? > What a plans with regard to > [staging] in the near future? If you don't do this

Re: [arch-dev-public] Adding !staticlibs to our default makepkg.conf

On Wed, May 29, 2013 at 3:31 AM, Allan McRae wrote: > We discussed removing static libraries for most packages back in March [1]. > > Now makepkg for pacman-4.1 has an option "staticlibs" that automatically > removes them. Should I make that the default in our makepkg.conf? Sounds like a reasonab

Re: [arch-dev-public] Removing glib 1, gtk 1 and qt3

On Wed, May 22, 2013 at 10:33 PM, Andrea Scarpino wrote: > On Wednesday 22 May 2013 10:20:42 Eric Bélanger wrote: >> Beside the fact that they are old, is there any reason to remove them from >> the repo? I maintain these threee packages and they are working well (no >> bug assigned). I don't see

Re: [arch-dev-public] Removing glib 1, gtk 1 and qt3

On Wed, May 22, 2013 at 10:24 PM, Giovanni Scafora wrote: > Il 21/05/2013 13:12, Jan Alexander Steffens ha scritto: > >> Greetings everypony, >> >> Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy >> libraries. >> >> Check "pactree -rs glib" and "pactree -rs qt3" for dependent pa

[arch-dev-public] [RFC] dropping LILO?

Hi guys, I was just going through some of the orphans in the usrmove TODO list and noticed that lilo is one of them. If no one wants to adopt it, perhaps we should drop it to the AUR. Or are there any reasons to keep it around? Cheers, Tom

Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Wed, May 15, 2013 at 1:02 PM, Bartłomiej Piotrowski wrote: > SMTP forwarders aren't as crucial as bash is, therefore I don't see any > reason to revert changes or delay moving binaries to /usr/bin. Just > message maintainer that his package is broken due to recent changes. I see that this is

Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

On Tue, May 14, 2013 at 10:49 PM, Dave Reisner wrote: > On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote: >> On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski >> wrote: >> > Date: Tuesday, May 14, 2013 @ 22:22:08 >> > Author: bpiotrowski >> > Revision: 90846 >> > >

[arch-dev-public] [RFC] Bluez 5

Hi guys, I would like to push Bluez 5 to the repos, and rename Bluez 4 to 'bluez4'. Some things still require Bluez 4, and the two can not be installed together, so this is how I propose to do it. We will have the following packages: bluez4: the bluetooth daemon, providing the old dbus interface

Re: [arch-dev-public] Merging the "bin" directories

On Sun, May 12, 2013 at 11:58 AM, Rémy Oudompheng wrote: >>> Is it safe to move a daemon to /usr/bin where any user can access its >>> binary (e.g. my cups pkg)? >>> >> >> Sure... They were not magically hidden when in /usr/sbin. >> > > It is even a pain that very useful binaries like ip, ifconfi

Re: [arch-dev-public] Merging the "bin" directories

On Sun, May 12, 2013 at 10:44 AM, Thomas Bächler wrote: > Am 12.05.2013 07:22, schrieb Allan McRae: >> I have created a TODO list with all packages that have files in /bin, >> /sbin or /usr/sbin. As the list is fairly long, the first pass will be >> to adjust as many packages as possible to insta

Re: [arch-dev-public] Merging the "bin" directories

On Sun, May 12, 2013 at 7:56 AM, Gerardo Exequiel Pozzi wrote: > Looks like we are going "one step" more compared to Fedora right? > > /bin /sbin /usr/sbin -> /usr/bin (Arch Linux) > /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora) Correct. For what it's worth, I asked the Fedora guys if there w

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

On Sun, May 5, 2013 at 9:00 PM, Tom Gundersen wrote: > On Sun, May 5, 2013 at 7:32 AM, Evangelos Foutras > wrote: >> On 5 May 2013 04:31, Jan Alexander Steffens wrote: >>> libtirpc 0.2.3-1 breaks pam_unix, making login and su(do) impossible: >>> >>> May 0

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

On Sun, May 5, 2013 at 7:32 AM, Evangelos Foutras wrote: > On 5 May 2013 04:31, Jan Alexander Steffens 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/se

Re: [arch-dev-public] [arch-general] [pacman-dev] debug package repositories

comes to having debug packages in a > separate repository. > > On 15 April 2013 15:00, Tom Gundersen wrote: >> Couldn't pacman be fixed to only show debug packages in search results when >> you ask for it with a switch? Maybe something similar could be done for >>

Re: [arch-dev-public] [arch-general] [pacman-dev] debug package repositories

On 15 Apr 2013 15:50, "Rashif Ray Rahman" wrote: > > On 15 April 2013 17:52, Allan McRae wrote: > > In fact, I will provide the needed patches for a separate [debug] and > > [community-debug] repo if that is what is decided to happen. > > I personally think that is the only way to go about it. I

Re: [arch-dev-public] [core] build failures - 2013/04/08

On Mon, Apr 8, 2013 at 2:30 PM, Allan McRae wrote: > FAIL: libtirpc > - autoreconf failure Pushed patch for this upstream yesterday. Waiting for feedback before releasing new version. Cheers, Tom

[arch-dev-public] [RFC] default sysctl settings

Hi guys, As you may have noticed systemd ships a default sysctl config file as of v199 (/usr/lib/sysctl.d/50-default.conf). Rather than also ship an Arch-specific one (/etc/sysctl.conf), should we try to unify the two? I had a look a the differences: 1) kernel.sysrq: We set it to 'off', systemd

[arch-dev-public] Fwd: [ANNOUNCE] util-linux v2.23-rc1

For your informawion. Please note that the tunelp tool has been deprecated and is no longer included. If this is a problem, please speak up now. I built and uploaded the release candidate for people to test: . Cheers, Tom -- Forwarded message -

Re: [arch-dev-public] BIND10? No, thanks.

On Wed, Mar 20, 2013 at 3:03 PM, Thomas Bächler wrote: > Am 20.03.2013 14:42, schrieb Tom Gundersen: >> On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee wrote: >>> host, nslookup, traceroute6- the list of extremely basic sysadmin >>> tools Arch doesn't ship in an easily

Re: [arch-dev-public] BIND10? No, thanks.

On Wed, Mar 20, 2013 at 2:59 PM, Dave Reisner wrote: > glibc ships getent, which can be used to do DNS lookups (getent hosts > www.google.com). That said, I don't expect people to know this offhand > as an alternative to dig. > > I'm kind of wary of not shipping *basic* DNS tools which people expe

Re: [arch-dev-public] BIND10? No, thanks.

On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee wrote: > host, nslookup, traceroute6- the list of extremely basic sysadmin > tools Arch doesn't ship in an easily installable fashion is starting > to get rather long. Does util-linux or such provide implementations of > the first two that until now we ha

Re: [arch-dev-public] [arch-releng] FYI: systemd 198

On Fri, Mar 8, 2013 at 10:06 AM, Gerardo Exequiel Pozzi wrote: > On 03/07/2013 09:35 PM, Tom Gundersen wrote: >> Hi guys, >> >> A new systemd release is out (not yet packaged though), and there are >> several features which might be of interest to

[arch-dev-public] FYI: systemd 198

u, Martin Pitt, Mauro Dreissig, Max F. Albrecht, Michael Biebl, Michael Olbrich, Michal Schmidt, Michal Sekletar, Michal Vyskocil, Michał Bartoszkiewicz, Mirco Tischler, Nathaniel Chen, Nestor Ovroy, Oleksii Shevchuk, Paul W. Frields, Piotr Drąg, Rob Clark,

Re: [arch-dev-public] gummiboot-efi still in testing

On Tue, Mar 5, 2013 at 8:40 PM, Tobias Powalowski wrote: > somehow gummiboot-efi is still in testing, while gummiboot package is > also there. > > Tom can you look at that and remove it? I'll move gummiboot to [extra] and remove gummiboot-efi everywhere soon. -t

Re: [arch-dev-public] Please provide Info for my talk!

On Mon, Feb 25, 2013 at 12:17 AM, Allan McRae wrote: > @Tom: I will ping you with what I got... In fact, you can also have a > copy of my talk! Thanks! > Disappointingly, I only have responses from 4 devs, 2 TU and 2 users. :(

Re: [arch-dev-public] Please provide Info for my talk!

On Tue, Feb 19, 2013 at 3:15 PM, Allan McRae wrote: > I am giving an hour long talk at the end of next week about Arch, how it > works and why we are successful. I will focus on stuff I am involved > with (i.e. pacman...), but will give examples of things like how we > decided on systemd, the new

Re: [arch-dev-public] mesa packaging, libGL handling

On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens wrote: > On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier wrote: >> Perhaps we could merge: >> - mesa, khrplatform-devel >> - libglapi, libgl, libgles >> - libgbm, libegl > > Also, the pipe drivers from libgbm should be sorted into the *-dri packages.

Re: [arch-dev-public] mesa packaging, libGL handling

On Fri, Feb 15, 2013 at 1:07 PM, Jan de Groot wrote: > At this moment our Mesa package is a mess. It contains several split > packages, some even just containing one file. Most of these packages > depend on eachother, so other than "let's make it look like Debian" I > don't see a big need for spli

[arch-dev-public] Bluez5.X

Hi guys, Another update on the Bluez front. I will, as advised by upstream, ship it as a split package, which should hopefully help with the transition. There will be the 'bluez' package containing the bluez and obex daemons, as well as a couple of universally useful tools. Packages that depend

Re: [arch-dev-public] [RFC] Add Wayland/Weston

On Tue, Feb 12, 2013 at 5:42 PM, Andreas Radke wrote: > Am Sat, 9 Feb 2013 17:35:27 +0100 > schrieb Andreas Radke : > >> Since cairo will also depend on that libegl then every system will >> pull in Wayland. Is this really needed? If we can't build it in a >> different way we directly need to move

Re: [arch-dev-public] [RFC] Add Wayland/Weston

On Feb 8, 2013 2:56 PM, "Jan de Groot" wrote: > > On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > > > I appreciate your effort and have no objection against adding Wayland. > > > > However, to limit people's enthusiasm about this, I just want to remark > > that having Wayland installed n

Re: [arch-dev-public] [RFC] Add Wayland/Weston

On Feb 8, 2013 2:56 PM, "Jan de Groot" wrote: > > On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: > > > I appreciate your effort and have no objection against adding Wayland. > > > > However, to limit people's enthusiasm about this, I just want to remark > > that having Wayland installed n

Re: [arch-dev-public] kdelibs / docbook-xsl

Please someone move it. Im not at home at the moment. T On Feb 8, 2013 12:01 PM, "Ike Devolder" wrote: > Hi, > > Is there something stopping us moving docbook-xsl and co to extra, > kdelibs 4.10.0-2 references to is and is already moved to extra > > thx > -- > Ike >

Re: [arch-dev-public] [RFC] Add Wayland/Weston

Hi Sébastien, Thanks for bringing this up! On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer wrote: > If the both maintainers agreed to add support, we need to find a > gentle developper which can move wayland to extra[5]. I'd be happy to take wayland to extra when the time comes. Just let m

Re: [arch-dev-public] JAVA_HOME in systemd

On Feb 6, 2013 3:09 PM, "Guillaume ALAUX" wrote: > > On 6 February 2013 15:08, Guillaume ALAUX wrote: > > -- Forwarded message -- > > From: Leonidas Spyropoulos > > Date: 6 February 2013 14:52 > > Subject: Re: [arch-dev-public] JAVA_HOME in systemd > > To: guilla...@archlinux.org

Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts

On Mon, Feb 4, 2013 at 3:00 AM, Dan McGee wrote: > * s/announced previously/previously announced/ > * still using them (instead of 'it') Thanks. Announcement posted. Will create todo and remove packages sometime today. Cheers, Tom

Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts

On Sun, Feb 3, 2013 at 12:18 PM, Pierre Schmitz wrote: >> No objections. Will you make a TODO list to remove the remaining files >> in /etc/rc.d? > > Maybe have a look at /etc/conf.d as well so we finally get consistent > here. Will do both. I suggest the following announcement (feel free to im

Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts

On Sat, Feb 2, 2013 at 12:18 AM, Tom Gundersen wrote: > To make our communication with our users clear I suggest we drop > initscripts I guess we should also drop 'sysvinit' and only keep 'sysvinit-tools' to avoid any confusion. -t

[arch-dev-public] [RFC] Finally dropping initscripts and rc scripts

Hi guys, Several devs have been asking me to officially drop initscripts, so I thought I'd bring it here. As per our announcement [0], the rc scripts have been unsupported for one month now, and we have slowly started removing them (which means stuff will have started breaking for people still us

Re: [arch-dev-public] sysvinit vs. sysvinit-compat

On Fri, Feb 1, 2013 at 8:06 PM, Eric Bélanger wrote: > On Fri, Feb 1, 2013 at 1:37 PM, Tobias Powalowski > wrote: >> Hi guys, >> Those packages have conflicts on each other, sysvinit-compat is in base >> group, >> so shouldn't sysvinit moved to extra? >> > > sysvinit is in a split PKGBUILD with s

Re: [arch-dev-public] Silent removal of initscripts?

On Mon, Jan 28, 2013 at 4:46 PM, Dan McGee wrote: > I know we posted a news item back in November about the deprecation of > old school rc.d scripts, but the current silent removal thing is not > real cool, and one never knows what package is going to fail to start > up next. Last week it was open

Re: [arch-dev-public] filesystem package

On Sun, Jan 27, 2013 at 1:55 AM, Allan McRae wrote: > Anyway, I say we can just remove post_install from filesystem and reduce > the dependencies to only iana-etc Yes please. This has long been on my low-priority TODO. > , and then make glibc depend on > filesystem. We can assume coreutils and b

Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])

On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae wrote: > There is nothing stopping us dropping vi completely and just putting vim > on the install media... I'd favor that (as a vim user who always gets confused by vi on the install media). -t

Re: [arch-dev-public] Winter Cleanup of [extra]

On Thu, Jan 24, 2013 at 4:08 PM, Andrea Scarpino wrote: > bluez-hcidump I adopted this. It will go away with the next bluez release. Cheers, Tom

Re: [arch-dev-public] systemd 197 - kdm fails

I'm using KDE as well, but have not been able to reproduce this problem. Any chance you could get some more debug info out of it? Sounds like something times out... On Fri, Jan 11, 2013 at 6:17 PM, Lukas Jirkovsky wrote: > On 8 January 2013 10:27, Thomas Bächler wrote: >> First of all, sorry for

Re: [arch-dev-public] network interface naming with systemd 197

On Jan 6, 2013 7:38 PM, "Dave Reisner" wrote: > > Just an FYI: > > Upstream pushed a commit[0] which gives network devices persistent, and > unique, names based on hardware attributes, avoiding the random kernel > names. While this solves a real problem, it's also a fairly jarring > change. For ex

[arch-dev-public] [BlueZ 5.0] minimum kernel version bump

Hi guys, BlueZ 5.0 has been released [0], which is incompatible with 4.X. For this reason I won't be pushing the release until all dependent packages are ready. Once this release is out, it will bump the minimum kernel requirement of BlueZ to 3.4, so users of the LTS kernel should be aware that t

Re: [arch-dev-public] [RFC] dbus cleanup

On Mon, Dec 3, 2012 at 11:55 AM, Dave Reisner wrote: > On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote: >> On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote: >> > While we're touching the PKGBUILD, why do we "fix" the configuration >> > file in the package function? Would be nice i

Re: [arch-dev-public] [RFC] dbus cleanup

On Dec 3, 2012 2:43 PM, "Jan de Groot" wrote: > > On ma, 2012-12-03 at 13:05 +0100, Tom Gundersen wrote: > > Any suggestions on how these messages can be avoided? > > You can't, unless you push an update for dbus-core first... There is no way to enforce that pe

Re: [arch-dev-public] [RFC] dbus cleanup

On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae wrote: > Some fun here... > > (1/1) removing dbus-core > [##] 100% > userdel: user dbus is currently used by process 336 > groupdel: cannot remove the primary group of user 'dbus' > error: command failed to execute correctly > > Obvi

Re: [arch-dev-public] [RFC] dbus cleanup

On Mon, Dec 3, 2012 at 10:07 AM, Jan de Groot wrote: > On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote: >> While we're touching the PKGBUILD, why do we "fix" the configuration >> file in the package function? Would be nice if we could cleanup the >> 30-dbus file as well to simply use shell bu

[arch-dev-public] [RFC] dbus cleanup

Hi guys, I'd like to propose the following change to our two dbus packages: * make libx11 an optdep in dbus * merge dbus-core into dbus * move dbus to [core] This should not have much of an effect in practice, but should make things a bit clearer and especially the naming will be more in-line

Re: [arch-dev-public] [RFC] the future of /media

On Thu, Nov 22, 2012 at 2:53 PM, Tom Gundersen wrote: > I suggest that we move /media from the filesystem to the udisks > package, allowing everyone else to do what they wish locally. I implemented this in the packages in [testing], so people can have a look. Cheers, Tom

  1   2   3   4   5   >