[arch-dev-public] Signoff report for [testing]

[Arch Website Notification]

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 7 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 7 fully signed off packages
* 22 packages missing signoffs
* 10 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (7 total) ==

* python-setuptools-1.3-1 (any)
* bluez-5.10-2 (i686)
* elfutils-0.157-1 (i686)
* system-config-printer-1.4.3-1 (i686)
* bluez-5.10-2 (x86_64)
* elfutils-0.157-1 (x86_64)
* system-config-printer-1.4.3-1 (x86_64)


== Incomplete signoffs for [core] (11 total) ==

* btrfs-progs-0.20rc1.3-2 (i686)
0/1 signoffs
* dhcpcd-6.1.0-1 (i686)
0/1 signoffs
* efivar-0.7-1 (i686)
0/1 signoffs
* grub-1:2.00.963.g93c1207-1 (i686)
0/1 signoffs
* iptables-1.4.20-1 (i686)
0/1 signoffs
* mdadm-3.3-2 (i686)
0/1 signoffs
* btrfs-progs-0.20rc1.3-2 (x86_64)
0/2 signoffs
* efivar-0.7-1 (x86_64)
1/2 signoffs
* grub-1:2.00.963.g93c1207-1 (x86_64)
0/2 signoffs
* mdadm-3.3-2 (x86_64)
1/2 signoffs
* openssl-1.0.1.e-5 (x86_64)
1/2 signoffs

== Incomplete signoffs for [extra] (11 total) ==

* python-setuptools-1.3-1 (any)
0/2 signoffs
* bluedevil-2.0-0.1 (i686)
0/1 signoffs
* bluez-5.10-2 (i686)
0/1 signoffs
* elfutils-0.157-1 (i686)
0/1 signoffs
* libbluedevil-2.0-0.1 (i686)
0/1 signoffs
* system-config-printer-1.4.3-1 (i686)
0/1 signoffs
* valgrind-3.9.0-1 (i686)
0/1 signoffs
* bluez-5.10-2 (x86_64)
0/2 signoffs
* elfutils-0.157-1 (x86_64)
0/2 signoffs
* system-config-printer-1.4.3-1 (x86_64)
0/2 signoffs
* valgrind-3.9.0-1 (x86_64)
0/2 signoffs


== Completed signoffs (7 total) ==

* iproute2-3.11.0-1 (i686)
* openssl-1.0.1.e-5 (i686)
* dhcpcd-6.1.0-1 (x86_64)
* iproute2-3.11.0-1 (x86_64)
* iptables-1.4.20-1 (x86_64)
* bluedevil-2.0-0.1 (x86_64)
* libbluedevil-2.0-0.1 (x86_64)


== All packages in [testing] for more than 14 days (10 total) ==

* bluedevil-2.0-0.1 (i686), since 2013-10-08
* bluedevil-2.0-0.1 (x86_64), since 2013-10-08
* libbluedevil-2.0-0.1 (i686), since 2013-10-08
* libbluedevil-2.0-0.1 (x86_64), since 2013-10-08
* iptables-1.4.20-1 (i686), since 2013-10-14
* iptables-1.4.20-1 (x86_64), since 2013-10-14
* iproute2-3.11.0-1 (i686), since 2013-10-14
* iproute2-3.11.0-1 (x86_64), since 2013-10-14
* dhcpcd-6.1.0-1 (i686), since 2013-10-14
* dhcpcd-6.1.0-1 (x86_64), since 2013-10-14


== Top five in signoffs in last 24 hours ==

1. pierre - 2 signoffs
2. thomas - 1 signoffs

[arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Alexander Rødseth]

Hi,

gnome-commander was last updated 2011-12-10, is currently an orphan
and no other package needs it.
https://www.archlinux.org/packages/community/x86_64/gnome-commander/

perl-config-ini was last updated 2013-10-28, is currently an orphan
and no other package needs it.
https://www.archlinux.org/packages/community/any/perl-config-ini/

I'm planning to move these two from [community] to AUR.

-- 
Best regards,
  Alexander Rødseth
  xyproto / TU

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Alexander Rødseth]

Note that perl-config-ini has been maintained by seblu since
2012-01-27, so he must have either actively disowned it, or never
adopted it in the first place. This is not a case of wanting to move a
package that has just been uploaded, but not adopted yet. See:
https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/perl-config-ini

Seblu, just adopt the package if you still want it, I won't move it
until after having heard from you.

-- 
Best regards,
  Alexander Rødseth
  xyproto / TU

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Andreas Radke]

Am Mon, 4 Nov 2013 11:54:25 +0100
schrieb Alexander Rødseth :

> Hi,
> 
> gnome-commander was last updated 2011-12-10, is currently an orphan
> and no other package needs it.
> https://www.archlinux.org/packages/community/x86_64/gnome-commander/
> 
> perl-config-ini was last updated 2013-10-28, is currently an orphan
> and no other package needs it.
> https://www.archlinux.org/packages/community/any/perl-config-ini/
> 
> I'm planning to move these two from [community] to AUR.
> 

Please keep gnome-commander for now, the package works pretty well so
far. After the initial upstream developer died it now has been picked up
and development seems to be started again.

It's my daily FM (I couldn't find another good gtk based two panel FM
so far) and I can help out Sergej if problems occur.

http://lists.nongnu.org/archive/html/gcmd-devel/2013-11/msg0.html

-Andy


signature.asc
Description: PGP signature

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Alexander Rødseth]

Hi,

Ok, adopted gnome-commander. Looking forward to seeing a release from
upstream in the future.

- Alexander

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Alexander Rødseth]

Hi,

gnome-commander doesn't compile. Do you still mind if I move it to AUR?


Here is one of the errors:


In file included from gnome-cmd-tags.cc:36:0:
./../dict.h: In instantiation of 'void DICT::add(KEY, const
VAL&) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]':
./../dict.h:155:10:   required from 'void load_data(DICT&,
void*, unsigned int) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]'
gnome-cmd-tags.cc:540:68:   required from here
./../dict.h:58:101: error: 'make_pair' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the
point of instantiation [-fpermissive]
 std::pair k_pos =
k_coll.insert(make_pair(k,(const VAL *) NULL));

  ^
In file included from /usr/include/c++/4.8.2/bits/stl_algobase.h:64:0,
 from /usr/include/c++/4.8.2/vector:60,
 from gnome-cmd-tags.cc:26:
/usr/include/c++/4.8.2/bits/stl_pair.h:286:5: note: 'template std::pair<_T1, _T2> std::make_pair(_T1, _T2)' declared
here, later in the translation unit
 make_pair(_T1 __x, _T2 __y)
 ^


-- 
Best regards,
  Alexander Rødseth
  xyproto / TU

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

[Tobias Powalowski]

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 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 essentially get a random driver
> loaded unless one of the two are blacklisted. Moreover, it is not
> possible to use both driver at the same time for different devices.
>
> It seems to me based on [1], that there is reason to doubt the
> validity of the modaliases that lirc_atiusb supports but ati_remote
> does not. I therefore suggest we drop lirc_atiusb and if there is
> fallout from this we try to fix that in ati_remote upstream (e.g. add
> missing modaliases).
>
> *) lirc_i2c: this was removed from staging in [2], as the
> functionality is replaced by ir-kbd-i2c (which appears to be written
> mostly by the same people). I suggest we remove this driver too as it
> appears to be redundant (though it has no autoloading support as far
> as I can tell, so probably less harmful).
>
> *) lirc_wpc8769l: I suggest we keep this as the only remaining module
> for now. Based on comments in winbond-cir [3], that driver can
> probably be extended to support WEC102* (WPC8769L is WEC1020). I'll
> get in touch with the maintainers to check it out.
>
> Any comments?
>
> Tom
>
> [0] compare the aliases as shown by 'modinfo'.
> [1] 
> 
> [2] 
> 
> [3] 
> 
Do the changes you think are best,
I never used lirc in any way.

greetings
tpowa

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org




signature.asc
Description: OpenPGP digital signature

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

[Tom Gundersen]

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 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 essentially get a random driver
>> loaded unless one of the two are blacklisted. Moreover, it is not
>> possible to use both driver at the same time for different devices.
>>
>> It seems to me based on [1], that there is reason to doubt the
>> validity of the modaliases that lirc_atiusb supports but ati_remote
>> does not. I therefore suggest we drop lirc_atiusb and if there is
>> fallout from this we try to fix that in ati_remote upstream (e.g. add
>> missing modaliases).
>>
>> *) lirc_i2c: this was removed from staging in [2], as the
>> functionality is replaced by ir-kbd-i2c (which appears to be written
>> mostly by the same people). I suggest we remove this driver too as it
>> appears to be redundant (though it has no autoloading support as far
>> as I can tell, so probably less harmful).

I got it confirmed from upstream that these are now redundant, so
removed them from svn.

>> *) lirc_wpc8769l: I suggest we keep this as the only remaining module
>> for now. Based on comments in winbond-cir [3], that driver can
>> probably be extended to support WEC102* (WPC8769L is WEC1020). I'll
>> get in touch with the maintainers to check it out.
>>
>> Any comments?
>>
>> Tom
>>
>> [0] compare the aliases as shown by 'modinfo'.
>> [1] 
>> 
>> [2] 
>> 
>> [3] 
>> 
> Do the changes you think are best,
> I never used lirc in any way.

We now only have one lirc kernel module left, according to [0] it does
not appear to be much used (i.e., not at all). If you want to avoid
having to rebuild lirc for every kernel release you might want to drop
the last module into the AUR, but I'll leave that decision up to you.

Cheers,

Tom

[0]: 

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 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 essentially get a random driver
>> loaded unless one of the two are blacklisted. Moreover, it is not
>> possible to use both driver at the same time for different devices.
>>
>> It seems to me based on [1], that there is reason to doubt the
>> validity of the modaliases that lirc_atiusb supports but ati_remote
>> does not. I therefore suggest we drop lirc_atiusb and if there is
>> fallout from this we try to fix that in ati_remote upstream (e.g. add
>> missing modaliases).
>>
>> *) lirc_i2c: this was removed from staging in [2], as the
>> functionality is replaced by ir-kbd-i2c (which appears to be written
>> mostly by the same people). I suggest we remove this driver too as it
>> appears to be redundant (though it has no autoloading support as far
>> as I can tell, so probably less harmful).
>>
>> *) lirc_wpc8769l: I suggest we keep this as the only remaining module
>> for now. Based on comments in winbond-cir [3], that driver can
>> probably be extended to support WEC102* (WPC8769L is WEC1020). I'll
>> get in touch with the maintainers to check it out.
>>
>> Any comments?
>>
>> Tom
>>
>> [0] compare the aliases as shown by 'modinfo'.
>> [1] 
>> 
>> [2] 
>> 
>> [3] 
>> 
> Do the changes you think are best,
> I never used lirc in any way.
>
> greetings
> tpowa
>
> --
> Tobias Powalowski
> Archlinux Developer & Package Maintainer (tpowa)
> http://www.archlinux.org
> tp...@archlinux.org
>
>

Re: [arch-dev-public] For Sale: sage-mathematics to a good home.

[Evgeniy Alekseev]

On Saturday 02 November 2013 21:28:29 Daniel Wallace wrote:
> Arcanis I saw you wanted to maintain some mathematics stuff, and I think at
> one point we had someone who helped write some of the sage-mathematics
> code.

Okay, I may maintaing it. But it looks some hardly ;)
-- 
С уважением, Е.Алексеев.
Sincerely yours, E.Alekseev.

e-mail: darkarca...@mail.ru
ICQ: 407-398-235
Jabber: arca...@jabber.ru

signature.asc
Description: This is a digitally signed message part.

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Ike Devolder]

On Mon, Nov 04, 2013 at 01:06:09PM +0100, Andreas Radke wrote:
> Am Mon, 4 Nov 2013 11:54:25 +0100
> schrieb Alexander Rødseth :
> 
> > Hi,
> > 
> > gnome-commander was last updated 2011-12-10, is currently an orphan
> > and no other package needs it.
> > https://www.archlinux.org/packages/community/x86_64/gnome-commander/
> > 
> > perl-config-ini was last updated 2013-10-28, is currently an orphan
> > and no other package needs it.
> > https://www.archlinux.org/packages/community/any/perl-config-ini/
> > 
> > I'm planning to move these two from [community] to AUR.
> > 
> 
> Please keep gnome-commander for now, the package works pretty well so
> far. After the initial upstream developer died it now has been picked up
> and development seems to be started again.
> 
> It's my daily FM (I couldn't find another good gtk based two panel FM
> so far) and I can help out Sergej if problems occur.
> 
> http://lists.nongnu.org/archive/html/gcmd-devel/2013-11/msg0.html
> 
> -Andy

Have you tried doublecmd ?

It is actively maintained and has a gtk and qt gui.

-- 
Ike


pgpMrCam5BIis.pgp
Description: PGP signature

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

[Ike Devolder]

On Mon, Nov 04, 2013 at 05:25:05PM +0100, Tom Gundersen wrote:
> 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 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 essentially get a random driver
> >> loaded unless one of the two are blacklisted. Moreover, it is not
> >> possible to use both driver at the same time for different devices.
> >>
> >> It seems to me based on [1], that there is reason to doubt the
> >> validity of the modaliases that lirc_atiusb supports but ati_remote
> >> does not. I therefore suggest we drop lirc_atiusb and if there is
> >> fallout from this we try to fix that in ati_remote upstream (e.g. add
> >> missing modaliases).
> >>
> >> *) lirc_i2c: this was removed from staging in [2], as the
> >> functionality is replaced by ir-kbd-i2c (which appears to be written
> >> mostly by the same people). I suggest we remove this driver too as it
> >> appears to be redundant (though it has no autoloading support as far
> >> as I can tell, so probably less harmful).
> 
> I got it confirmed from upstream that these are now redundant, so
> removed them from svn.
> 
> >> *) lirc_wpc8769l: I suggest we keep this as the only remaining module
> >> for now. Based on comments in winbond-cir [3], that driver can
> >> probably be extended to support WEC102* (WPC8769L is WEC1020). I'll
> >> get in touch with the maintainers to check it out.
> >>
> >> Any comments?
> >>
> >> Tom
> >>
> >> [0] compare the aliases as shown by 'modinfo'.
> >> [1] 
> >> 
> >> [2] 
> >> 
> >> [3] 
> >> 
> > Do the changes you think are best,
> > I never used lirc in any way.
> 
> We now only have one lirc kernel module left, according to [0] it does
> not appear to be much used (i.e., not at all). If you want to avoid
> having to rebuild lirc for every kernel release you might want to drop
> the last module into the AUR, but I'll leave that decision up to you.
> 
> Cheers,
> 
> Tom
> 
> [0]: 
> 
> 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 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 essentially get a random driver
> >> loaded unless one of the two are blacklisted. Moreover, it is not
> >> possible to use both driver at the same time for different devices.
> >>
> >> It seems to me based on [1], that there is reason to doubt the
> >> validity of the modaliases that lirc_atiusb supports but ati_remote
> >> does not. I therefore suggest we drop lirc_atiusb and if there is
> >> fallout from this we try to fix that in ati_remote upstream (e.g. add
> >> missing modaliases).
> >>
> >> *) lirc_i2c: this was removed from staging in [2], as the
> >> functionality is replaced by ir-kbd-i2c (which appears to be written
> >> mostly by the same people). I suggest we remove this driver too as it
> >> appears to be redundant (though it has no autoloading support as far
> >> as I can tell, so probably less harmful).
> >>
> >> *) lirc_wpc8769l: I suggest we keep this as the only remaining module
> >> for now. Based on comments in winbond-cir [3], that driver can
> >> probably be extended to support WEC102* (WPC8769L is WEC1020). I'll
> >> get in touch with the maintainers to check it out.
> >>
> >> Any comments?
> >>
> >> Tom
> >>
> >> [0] compare the aliases as shown by 'modinfo'.
> >> [1] 
> >> 
> >> [2] 
> >> 
> >> [3] 
> >> 
> > Do the changes you think are best,
> > I never used lirc in any way.
> >
> > greetings
> > tpowa
> >
> > --
> > Tobias Powalowski
> > Archlinux Developer & Package Maintainer (tpowa)
> > http://www.archlinux.org
> > tp...@archlinux.org
> >
> >

Just drop lirc.

I have used it in the past and sw

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Andreas Radke]

Am Mon, 4 Nov 2013 18:54:29 +0100
schrieb Ike Devolder :

> Have you tried doublecmd ?
> 
> It is actively maintained and has a gtk and qt gui.

Looks promising. Thx.

-Andy 


signature.asc
Description: PGP signature

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Andreas Radke]

Am Mon, 4 Nov 2013 13:39:48 +0100
schrieb Alexander Rødseth :

> Hi,
> 
> gnome-commander doesn't compile. Do you still mind if I move it to
> AUR?
> 
> 
> Here is one of the errors:
> 
> 
> In file included from gnome-cmd-tags.cc:36:0:
> ./../dict.h: In instantiation of 'void DICT::add(KEY, const
> VAL&) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]':
> ./../dict.h:155:10:   required from 'void load_data(DICT&,
> void*, unsigned int) [with KEY = GnomeCmdTag; VAL = GnomeCmdTagName]'
> gnome-cmd-tags.cc:540:68:   required from here
> ./../dict.h:58:101: error: 'make_pair' was not declared in this scope,
> and no declarations were found by argument-dependent lookup at the
> point of instantiation [-fpermissive]
>  std::pair k_pos =
> k_coll.insert(make_pair(k,(const VAL *) NULL));
> 
>   ^
> In file included from /usr/include/c++/4.8.2/bits/stl_algobase.h:64:0,
>  from /usr/include/c++/4.8.2/vector:60,
>  from gnome-cmd-tags.cc:26:
> /usr/include/c++/4.8.2/bits/stl_pair.h:286:5: note: 'template _T1, class _T2> std::pair<_T1, _T2> std::make_pair(_T1, _T2)' declared
> here, later in the translation unit
>  make_pair(_T1 __x, _T2 __y)
>  ^
> 
> 

http://pkgs.fedoraproject.org/cgit/gnome-commander.git/tree/gnome-commander-1.2.8.15-gcc47.patch?id=eaa0a46abc3dc6ecdaa539be5e2f556d680e

With this fix it builds well here.

-Andy


signature.asc
Description: PGP signature

Re: [arch-dev-public] Moving two unneeded orphans from [community] to AUR

[Sébastien Luttringer]

On 04/11/2013 11:54, Alexander Rødseth wrote:
> gnome-commander was last updated 2011-12-10, is currently an orphan
> and no other package needs it.
> https://www.archlinux.org/packages/community/x86_64/gnome-commander/
> 
> perl-config-ini was last updated 2013-10-28, is currently an orphan
> and no other package needs it.
> https://www.archlinux.org/packages/community/any/perl-config-ini/
> 
> I'm planning to move these two from [community] to AUR.
> 

I recently disowned perl-config-ini and perl-mixin-linewise to let a
perl addict TU the opportunity to adopt them. They are no more
dependency of a package I use.

Is there any reason to remove it? Are you hunting orphan packages?

-- 
Sébastien "Seblu" Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature