[arch-dev-public] Stepping back as Arch Linux developer

[Daniel Isenmann]

Hi there,

that wasn't an easy decision, but after months of inactivity and only
sporadic checks of the mailing lists and emails, I have decided to step
back. My interests moved and my free time is limited and Arch Linux
deserves more time than I can actually offer.

It was a fantastic and excited journey over all these years. It was great
to be part of this community. I have met interesting people along the way,
had interesting discussions and learned a lot.

I wish Arch Linux and each of you all the best. Nevertheless I will be
around as a user.

Keep Arch Linux rolling

Cheers
Daniel

Re: [arch-dev-public] Shadowing i686, round 1

[Daniel Isenmann]

Bartłomiej Piotrowski  schrieb am Mo., 12. Dez.
2016 um 21:51 Uhr:

>
> I'd like to set a certain date of dropping i686 completely. During that
> time, community and/or interested packagers could come up with either
> automated build solution, making it "tier 2" architecture. Otherwise it
> would just die of natural cause.
>
> Let's see where we end up this time.
>
> Bartłomiej
>
>
+1 from me. Let's drop i686, I don't have one since years. Can't remember
when my last boot of an i686 system was

Cheers
Daniel

Re: [arch-dev-public] Orphaning and removing banshee from [extra]

[Daniel Isenmann]

Package removed from the repository...


Daniel Isenmann <dan...@archlinux.org> schrieb am Do., 6. Okt. 2016 um
18:46 Uhr:

> Hi,
>
> I'm going to orphaning banshee and two packages which are only required by
> banshee (gudev-sharp and gdata-sharp). There were no new version since ages
> and I don't use it anymore. Looking at their git repository shows only some
> small fixes and translation updates, but no really active development
> anymore since 2014!
>
> If someone wants it, feel free to adopt it. Otherwise I will remove the
> package from the repository completely in about a week. I won't move it to
> AUR, so if the community want to take care, feel free to publish it there.
>
> Any obections?
>
> Cheers
> Daniel
>

Re: [arch-dev-public] Long out of date packages

[Daniel Isenmann]

>
>
> ## Still required
> gdata-sharp
> gudev-sharp
>
>
Will be removed from the repo soon, because I decided to remove banshee
from the repo (reason here:
https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028361.html
)

As I stated in the other mail, I won't move it to the AUR.

Re: [arch-dev-public] Long out of date packages

[Daniel Isenmann]

2016-10-20 14:25 GMT+02:00 Florian Pritz via arch-dev-public <
arch-dev-public@archlinux.org>:

> On 28.09.2016 15:37, Florian Pritz via arch-dev-public wrote:
>
>
> daniel:
> extra/any/monodevelop
>
>
>
>
I'm on it. There is some compiing issues right now, that's the reason for
outdated. So don't move or orphan it, I will take care of this.

Cheers
Daniel

[arch-dev-public] Orphaning and removing banshee from [extra]

[Daniel Isenmann]

Hi,

I'm going to orphaning banshee and two packages which are only required by
banshee (gudev-sharp and gdata-sharp). There were no new version since ages
and I don't use it anymore. Looking at their git repository shows only some
small fixes and translation updates, but no really active development
anymore since 2014!

If someone wants it, feel free to adopt it. Otherwise I will remove the
package from the repository completely in about a week. I won't move it to
AUR, so if the community want to take care, feel free to publish it there.

Any obections?

Cheers
Daniel

Re: [arch-dev-public] Orphaning dhcp, looking for a maintainer

[Daniel Isenmann]

Thanks for adopting it. I have assigned 3 more bugs to you which was
assigned to me in flyspray. Nothing big I think, but I had not the time to
fix them.

Cheers
Daniel

Felix Yan <felixonm...@archlinux.org> schrieb am Do., 10. Sep. 2015 um
08:42 Uhr:

> On 09/10/2015 01:26 AM, Daniel Isenmann wrote:
> > Hi,
> >
> > anyone interested in dhcp/dhclient package in [extra] repository? I don't
> > use it anymore and its used by archboot and some other network package
> from
> > [extra].
> >
> > I have orphaned it already, so feel free to adopt it.
>
> Adopted and updated, also addressed the only one open issue on flyspray.
> Please let me know if anything else is needed, thanks.
>
> --
> Regards,
> Felix Yan
>
>

[arch-dev-public] Orphaning dhcp, looking for a maintainer

[Daniel Isenmann]

Hi,

anyone interested in dhcp/dhclient package in [extra] repository? I don't
use it anymore and its used by archboot and some other network package from
[extra].

I have orphaned it already, so feel free to adopt it.

Cheers
Daniel

Re: [arch-dev-public] Heads up: Changes in the next mono release

[Daniel Isenmann]

Long time no new information about this topic, but finally the mono 4.0
release is nearly out and the release is in the next few days. At the
moment I'm away until Thursday next week. I will prepare the new release
after my holiday.

I will try to make it as smooth as possible. Let's hope the best. ;-)

Here is the draft release note:
http://www.mono-project.com/docs/about-mono/releases/4.0.0/

Cheers,
Daniel

Daniel Isenmann dan...@archlinux.org schrieb am Sa., 10. Jan. 2015 13:59:

 Hi,

 I just read an email from Miguel (Mono head developer) that in the next
 mono release (I don't know when this will be) the .NET profile 2.0 and 4.0
 will be removed. So the reference assemblies of .NET 2.0 and 4.0 will be no
 longer in the package. As it seems the new mono release will have the
 version 4.0, so they are doing a major version bump.

 If you need them you have to stay with mono 3.10.0 or someone should
 maintain an AUR package which provides these assemblies.

 If someone wants to read the discussion on the mono mailinglist you can
 find it on the mail archive webpage:
 https://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg30995.html

 The packages which are provided in our repositories will be working with
 the new mono release, I will take care of this and move the new mono
 release to our repository only if all packages are working with it. If this
 doesn't work, maybe I will provide an old mono3 package and a new mono
 package for version = 4. If this is possible, have to check this first.

 For all the AUR packages you are on your own to check them.

 Cheers
 Daniel

[arch-dev-public] Moving wicd to [community] or AUR

[Daniel Isenmann]

Hi,

I no longer use wicd and the last (feature) release is from 2012, so I will
orphan this and if anyone is interested in maintaing it, please do so. They
have released a new version in December, but it doesn't really work stable
(at least on my PC).

If no one has adopt it until end of January, I will move it to AUR.

Any objections or comments?

Cheers
Daniel

[arch-dev-public] Heads up: Changes in the next mono release

[Daniel Isenmann]

Hi,

I just read an email from Miguel (Mono head developer) that in the next
mono release (I don't know when this will be) the .NET profile 2.0 and 4.0
will be removed. So the reference assemblies of .NET 2.0 and 4.0 will be no
longer in the package. As it seems the new mono release will have the
version 4.0, so they are doing a major version bump.

If you need them you have to stay with mono 3.10.0 or someone should
maintain an AUR package which provides these assemblies.

If someone wants to read the discussion on the mono mailinglist you can
find it on the mail archive webpage:
https://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg30995.html

The packages which are provided in our repositories will be working with
the new mono release, I will take care of this and move the new mono
release to our repository only if all packages are working with it. If this
doesn't work, maybe I will provide an old mono3 package and a new mono
package for version = 4. If this is possible, have to check this first.

For all the AUR packages you are on your own to check them.

Cheers
Daniel

Re: [arch-dev-public] Disable corepkg?

[Daniel Isenmann]

That was my fault. I have accidentally released pptpclient to [extra]
yesterday, so the package was already released there and an old version was
in [core].

I have decided that it would be better to move it to [core] directly
because everybody who use the package already have installed it.

This will not happen again, and I don't see a reason to remove corepkg from
devtools.

So -1 from my side.

Cheers,
Daniel
Am 27.06.2014 23:03 schrieb Florian Pritz bluew...@xinu.at:

 On 27.06.2014 22:34, Dan McGee wrote:
  Have we had any actual problems with this? I'm probably the only one
  guilty of pushing straight to core (with pacman-mirrorlist), so I can
 adopt
  the new method, just curious if this is in reaction to something
 happening.

 pptpclient got pushed to core after a discussion on IRC which I readly
 shortly and it seemed that it should have gone to testing.

Re: [arch-dev-public] clean up home folders brynhild

[Daniel Isenmann]

On Wed, 2014-04-09 at 19:29 +0300, Ionuț Bîru wrote:
 Hey guys,
 
 Just ordered our new build server. Since now we have 2x240G SSD(not a lot
 of storage space), I want to do raid1 and I want to rsync /home very fast
 :D.
 
 Please delete whatever you don' t need from /home. With this occasion, I'm
 going to delete all the inactive trusted and developers accounts.
 

Done, nearly all files and directories deleted. ;-)

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

[Daniel Isenmann]

Am 04.12.2013 00:21, schrieb Sébastien Luttringer:

On 28/11/2013 22:33, Sébastien Luttringer wrote:

On 28/11/2013 07:22, Daniel Isenmann wrote:

Am 28.11.2013 02:15, schrieb Sébastien Luttringer:

On 27/11/2013 15:31, Sébastien Luttringer wrote:

On 27/11/2013 14:57, Alexander Rødseth wrote:

Daniel, could you handle the renaming and replacing of docker by
docker-tray[1] in extra (I cannot do it)? That let me push new docker as
soon as it's ready.


Daniel,

new docker is in community svn and ready to be pushed. PKGBUILD I
provided to you should allow smooth upgrade for users. Is there
something I can do to help you to go through this?

Cheers,

Can another dev do this step? I have nearly no free time at the moment 
to do anything. Would be great if someone can do this.


Thanks
Daniel

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

[Daniel Isenmann]

Am 27.11.2013 12:58, schrieb Tom Gundersen:

On Wed, Nov 27, 2013 at 12:49 PM, Sébastien Luttringer se...@seblu.net 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.

Allan

Usage instructions generally don't belong into install/upgrade messages.
In the best case, there is no message at all.

In this case, the install message contains basic systemctl commands and
networking tips, none of this is specific to docker or urgent enough to
be printed during pacman.



This package has been pushed to svn too quicly. A discussion has been
started in aur-general[1] and I stated that I'll managing addition.

After a quick talk with Allan, I sent a mail to Daniel, to see if we can
use the name docker for the new package instead of docker-io or
lxc-docker. Let time to Daniel to answer.

On the technical standpoint, this package needs refactoring, maybe build
the binary from the source and not use the binary provided by
dotcloud/docker inc. This needs more work to be done.

Cheers,

[1]
https://mailman.archlinux.org/pipermail/aur-general/2013-November/026223.html

This makes sense to me. It may be worth noting that the 'old' docker
is installed by roughly 1% of our users, but according to their
website is meant for use with GNOME2 and KDE3, which we don't even
ship any more. I'd say dropping or renaming it makes the most sense
and let this new package take the name 'docker', as that's what people
will be looking for.

Cheers,

Tom


Hi,

the 'old' docker ist mainly used for windowmaker and not GNOME2 or KDE3. 
Beside that it's working very well even it wasn't updated for decades.
Nevertheless I don't care what package name the 'old' docker have, so 
feel free to rename it to 'docker-tray' or something similar. But I 
don't see the case for moving or dropping it out of extra.


But how can we rename it without much hassle for the user? A provide 
line in the PKGBUILD isn't possible if the 'new' docker is called docker 
or am I wrong on this?


Cheers,
Daniel

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

[Daniel Isenmann]

Am 28.11.2013 02:15, schrieb Sébastien Luttringer:

On 27/11/2013 15:31, Sébastien Luttringer wrote:

On 27/11/2013 14:57, Alexander Rødseth wrote:

A bit sad to be starting out the new docker package with the mark of
shame (epoch=1), but so be it. ;)


I'm waiting some answer before pushing this package in our repository.

I got answers/help from upstream. I want underline that they are really
nice and it's a pleasure to work with them.

So, I built a fresh new PKGBUILD[1] for 0.7.0.

Some notes on differences with AUR version:
- docker is built dynamically (and no more upstream blob)
- use upstream version for bash and zsh completions
- move of dockerinit from /usr/libexec to /usr/lib/docker [2]
- use improved systemd service file (e.g make-rpivate) [3]

Now I need to test this new package more deeply.

And we're waiting for Daniel words about renaming current docker
package. In case this is not possible, upstream advice to use lxc-docker[4].


I had already answered:

-
Hi,

the 'old' docker ist mainly used for windowmaker and not GNOME2 or KDE3. 
Beside that it's working very well even it wasn't updated for decades.
Nevertheless I don't care what package name the 'old' docker have, so 
feel free to rename it to 'docker-tray' or something similar. But I 
don't see the case for moving or dropping it out of extra.


But how can we rename it without much hassle for the user? A provide 
line in the PKGBUILD isn't possible if the 'new' docker is called docker 
or am I wrong on this?


Cheers,
Daniel
--

That was the reason for the discussion about the way we should rename it 
and the epoch=1 solution which Alexander mentioned.  ;-)


Cheers,
Daniel

[arch-dev-public] Pushing mono to the next level

[Daniel Isenmann]

Hi,

long time no update from my side, but now I return with the push of mono
to the release 3.0.7. Also monodevelop get the latest version to 4.0.8.

I have tested the most mono-related packages (the most which I use on my
computer) and I haven't found any errors. If you found any bugs, please
report them to the bugtracker.

I will update the next mono-related packages the next days to update the
whole mono framework in our repo.

 -Daniel

Re: [arch-dev-public] [REMINDER] systemd conversion

[Daniel Isenmann]

On Thu, 2012-10-04 at 20:27 +0200, Tom Gundersen wrote: 
 On Thu, Oct 4, 2012 at 8:16 PM, Tom Gundersen t...@jklm.no wrote:
  Hi guys,
 
  Thanks to everyone who converted their packages to use native systemd
  service files since my last email.
 
  There are stil 66 packages remaining in our TODO however (10 from
  extra and the rest from community):
  https://www.archlinux.org/todo/178/.
 
 I got a request from a user eager to help to post the full list (our
 TODO lists are password protected, mostly by accident I think):

 x86_64Extra   mono2.10.8-1daniel  Incomplete
 x86_64Extra   xsp 2.10.2-3daniel  Incomplete

Hi,

feel free to do the above packages. I'm totally busy with my real life
right now and don't have time to do it at the moment.

- Daniel

Re: [arch-dev-public] Removing gimp-devel from [extra]

[Daniel Isenmann]

On Mon, 4 Jun 2012 19:49:14 +0200
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 Hi,
 
 I would like to move gimp-devel to AUR. At the moment, I'm the
 maintainer of gimp and gimp-devel, but I don't see any reason for the
 devel package in our repository. These are not the development files
 for gimp, it's the next devel branch for the next version (just for
 clarification).
 
 I will move it tomorrow, if no objections appears.
 
  Daniel

Removed from [extra] and moved to AUR...
  
 Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Fwd: limits.conf and fork bombing

[Daniel Isenmann]

Am 05.06.2012 14:26, schrieb Dave Reisner:

On Tue, Jun 05, 2012 at 02:23:34PM +0200, Tobias Powalowski wrote:


 Original-Nachricht 
Betreff:limits.conf and fork bombing
Datum:  Tue, 5 Jun 2012 13:15:26 +0200
Von:M0Rf30morf3...@gmail.com
An: tp...@archlinux.org



Could you insert a string into /etc/security/limits.conf to prevent a
fork bombing attack?
An example:
*hardnproc  300
Thanks
Best Regards
Gianluca Boiano


Yeah, we've seen this before...

https://bugs.archlinux.org/task/25690

d

Isn't this a task for the administrator of the computer? I don't see a 
reason, why we should add one for default in one of our packages.


 Daniel

Re: [arch-dev-public] Time to go

[Daniel Isenmann]

Am 05.06.2012 14:31, schrieb Paul Mattal:

All,

I've been inactive as a developer for a long time now, and I think 
it's time for me to go.


It's been an exciting ride with you all. I came on to help launch the 
AUR in 2005, and we changed the Arch world forever.


I encourage the new folks to think boldly and put your efforts and 
persistence into making the world better, one incremental improvement 
at a time-- and remember to have fun along the way!


Best,
Paul

P.S. Dan, or anyone with uber access, can you take care of closing my 
shell access and removing me from the dev mailing lists?


Thanks for all the work you have put into Arch Linux!

Wish you all the best for your tasks after your time here.

 Daniel

[arch-dev-public] Removing gimp-devel from [extra]

[Daniel Isenmann]

Hi,

I would like to move gimp-devel to AUR. At the moment, I'm the
maintainer of gimp and gimp-devel, but I don't see any reason for the
devel package in our repository. These are not the development files
for gimp, it's the next devel branch for the next version (just for
clarification).

I will move it tomorrow, if no objections appears.

 Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Google+ Hangout

[Daniel Isenmann]

Jan Steffens jan.steff...@gmail.com schrieb:

On Sat, May 19, 2012 at 7:56 PM, Daniel Isenmann daniel.isenm...@gmx.de wrote:
 Hi,

 it took a little bit longer, but here is the date for our first Google+
 Hangout. Some devs know what I mean, for all the others a short
 explanation.

 I had a discussion with some devs on Google+
 (https://plus.google.com/u/0/112342248775237115466/posts/ZufJjeLNCUB)
 about doing a hangout, see it like an inofficial developer meeting
 with audio and video. There will be no agenda (not from my side), but if
 anyone wants to talk about specific topics nobody will stop him. :)

 My main reason for doing such a hangout is to get to know the devs
 behind the email address. I know some of the devs from conferences or
 from pictures only, this will be the chance to see and talk to each
 other. If someone is afraid of talking English, there is also a text
 chat beside the hangout. ;-)

 You will need the following plugin from AUR for hangouts:
 http://aur.archlinux.org/packages.php?ID=40056

 Now about the date and time. I know that it's hard to find a date where
 everybody has time and the different time zones are the next big issue
 to solve.

 My suggestion will be Sunday May 27th, 7:00pm (CEST). This is
 1:00pm (EST) and sadly for our devs down under this will be Sunday 28th,
 1:00am (AEST).


 I will start the hangout from our Arch Linux G+ page and will invite
 all the devs I know on G+ to the given time.

 Feel free to add any topic if you want talk about it or if you have any
 other suggestions.

  Daniel

 PS: This won't be our last hangout, so if you can't join for this one,
 then maybe the next one ;-)

Will this be On Air or not? I won't be able to join the former.

If not, see you there!


No, this will be no On Air. I can't join them, too. It will be a normal 
hangout.

Daniel

Re: [arch-dev-public] Google+ Hangout

[Daniel Isenmann]

On Sat, 19 May 2012 19:56:43 +0200
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 Hi,
 
 it took a little bit longer, but here is the date for our first
 Google+ Hangout. Some devs know what I mean, for all the others a
 short explanation.
 
 I had a discussion with some devs on Google+
 (https://plus.google.com/u/0/112342248775237115466/posts/ZufJjeLNCUB)
 about doing a hangout, see it like an inofficial developer meeting
 with audio and video. There will be no agenda (not from my side), but
 if anyone wants to talk about specific topics nobody will stop him. :)
 
 My main reason for doing such a hangout is to get to know the devs
 behind the email address. I know some of the devs from conferences or
 from pictures only, this will be the chance to see and talk to each
 other. If someone is afraid of talking English, there is also a text
 chat beside the hangout. ;-)
 
 You will need the following plugin from AUR for hangouts:
 http://aur.archlinux.org/packages.php?ID=40056
 
 Now about the date and time. I know that it's hard to find a date
 where everybody has time and the different time zones are the next
 big issue to solve. 
 
 My suggestion will be Sunday May 27th, 7:00pm (CEST). This is
 1:00pm (EST) and sadly for our devs down under this will be Sunday
 28th, 1:00am (AEST).
 
 
 I will start the hangout from our Arch Linux G+ page and will invite
 all the devs I know on G+ to the given time.
 
 Feel free to add any topic if you want talk about it or if you have
 any other suggestions. 
 
  Daniel
 
 PS: This won't be our last hangout, so if you can't join for this one,
 then maybe the next one ;-)


Some more information about the hangout. You will need a headphone
otherwise there can be some echoes at the voice chat and you will need
a webcam ;-)

Due some restrictions from Google there can only be a
maximum of 10 people in one hangout, so first come first serve. All the
others will get a notification that the hangout is full. But you can
join if another is leaving the hangout. We have to check how we can
handle this if there are more than 10 devs who try to join. 

I would suggest that every dev who join the hangout is also logged in
at out IRC dev channel.

See you guys next Sunday

 Daniel




signature.asc
Description: PGP signature

[arch-dev-public] Google+ Hangout

[Daniel Isenmann]

Hi,

it took a little bit longer, but here is the date for our first Google+
Hangout. Some devs know what I mean, for all the others a short
explanation.

I had a discussion with some devs on Google+
(https://plus.google.com/u/0/112342248775237115466/posts/ZufJjeLNCUB)
about doing a hangout, see it like an inofficial developer meeting
with audio and video. There will be no agenda (not from my side), but if
anyone wants to talk about specific topics nobody will stop him. :)

My main reason for doing such a hangout is to get to know the devs
behind the email address. I know some of the devs from conferences or
from pictures only, this will be the chance to see and talk to each
other. If someone is afraid of talking English, there is also a text
chat beside the hangout. ;-)

You will need the following plugin from AUR for hangouts:
http://aur.archlinux.org/packages.php?ID=40056

Now about the date and time. I know that it's hard to find a date where
everybody has time and the different time zones are the next big issue
to solve. 

My suggestion will be Sunday May 27th, 7:00pm (CEST). This is
1:00pm (EST) and sadly for our devs down under this will be Sunday 28th,
1:00am (AEST).


I will start the hangout from our Arch Linux G+ page and will invite
all the devs I know on G+ to the given time.

Feel free to add any topic if you want talk about it or if you have any
other suggestions. 

 Daniel

PS: This won't be our last hangout, so if you can't join for this one,
then maybe the next one ;-)


signature.asc
Description: PGP signature

[arch-dev-public] Orphaned rp-pppoe in [core]

[Daniel Isenmann]

Hi,

I have orphaned the above package because I can't test it all. I don't
use pppoe to connect to the internet, so feel free to adopt it. It
hadn't much upstream updates so far, so should be easy to maintain.

Package: https://www.archlinux.org/packages/core/i686/rp-pppoe/

One bug is assigned to the package:
https://bugs.archlinux.org/task/26352

 -Daniel


signature.asc
Description: PGP signature

[arch-dev-public] Removed gecko-sharp-2.0 from [extra]

[Daniel Isenmann]

Hi,

I have removed gecko-sharp-2.0 from our repositories, it doesn't work at 
all since xulrunner removed Gtkmozembed from their package. No package 
needs gecko-sharp-2.0 anymore, so it's useless in our repo. If you want 
further information (of a nearly monologue from me on the mono-devel 
ML,) following the link: 
http://lists.ximian.com/pipermail/mono-devel-list/2012-March/038637.html


 -Daniel

Re: [arch-dev-public] Cleaning up orphaned packages

[Daniel Isenmann]

On Fri, 24 Feb 2012 16:19:25 +0100
Pierre Schmitz pie...@archlinux.de wrote:

 Hi all,
 
 while the rebuild of unsigned packages is about to be finished we
 should start to think about our orphaned packages. ATM there about 430
 of them in core and extra 1); some of them are 8probably) not needed
 by any other package 2)
 
 Here is my proposal:
 * Everybody please review the list and adopt packages that you use and
 might be willing to maintain.
 * If you maintain a package that depends on an orphan, please adopt
 it. It does not make sense to depend on an maintained package. Note
 that packages can have mroe than one maintainer; so you should share
 the workload.
 * If a TU wants to maintain an orphan that is currently in [extra],
 please let us know.
 * Maybe we can also have a small team that adopts all orphans that
 nobody wants to adopt on their own but is needed.
 
 The goal should be to adopt all needed/wanted orphans and remove
 everything else.
 
 Greetings,
 
 Pierre
 
 
 1)
 https://www.archlinux.org/packages/?sort=arch=anyarch=x86_64repo=Corerepo=Extraq=maintainer=orphanlast_update=flagged=limit=50
 2) https://www.archlinux.org/devel/reports/unneeded-orphans/
 

I have adopted some packages, mostly which I'm using in my daily work
with my computer. 

Following packages adopted:
 - GIMP
 - hugin (with deps):
   - autopano-sift-c
   - enblend-enfuse
   - exiv2
   - lcms
   - libpano13
 - bogofilter
 - banshee (with all deps)


 -Daniel


signature.asc
Description: PGP signature

[arch-dev-public] Mono and xyz-sharp (mono-related) packages in our repos

[Daniel Isenmann]

Hi,

I know that some of you avoid to install any of the mono or mono-related 
packages. But that's another topic, so no posts about how bad mono is 
or similar, don't want to start a flame war here.


We have plenty of mono and mono related packages in our repo, most of 
them are maintained by me. Some xyz-sharp library packages are 
maintained by other devs. Recently Pierre moved banshee out of our repo 
because it was unmaintained and no one wanted to maintain it. I have put 
it back to our repo, because I use it as my main media player and didn't 
know that it was unmaintained. But that is too much information for this 
mail.


Back to business: just a short call from my side to you, if you no 
longer want to maintain a xyz-sharp library package or other mono 
related package and you are thinking about moving it to the AUR or 
community, then please contact me first. I'm more than willing to adopt 
any mono related package in our repo to keep our mono stack up-to-date.


That's all...thanks.

 -Daniel

[arch-dev-public] Drop windowmaker-crm-git from [extra], use windowmaker package

[Daniel Isenmann]

Hi,

now that Window Maker development resumed and the new source for the 
official Window Maker package is the git repository of crm, there is no 
need anymore to have the crm-git package in the [extra] repository 
beside the official stable package. I will move it to AUR soon and will 
maintain it at the AUR.


To all the users of the windowmaker-crm-git package, please install the 
windowmaker package from the [extra] repository, which is the latest 
stable source from windowmaker.org and even newer than the crm-git 
package. All features which are in the crm-git package are merged to the 
official windowmaker package because of the same source.


 -Daniel

[arch-dev-public] Removed gluezilla from the repository

[Daniel Isenmann]

Hi,
I have removed gluezilla from the [extra] repository. gluezilla was a
C#/Mono-Wrapper for xulrunner, but it seems that the project itself
isn't updated anymore since nearly 2 years now. It won't compile with
the newest xulrunner and it was on the list of rebuilds for libpng1.5.
No other package requires gluezilla, so this doesn't have any
effect on any other package in our repos.

 -Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] WindowMaker is back again

[Daniel Isenmann]

On Sun, 8 Jan 2012 19:05:50 +0100
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 Hi,
 
 I think everybody knows that WindowMaker development was stalled since
 ages. It started again with the windowmaker-crm git repository. Now
 windowmaker-crm is the most up-to-date source and is considered as the
 official release. (Stated on the new website: http://windowmaker.org/)
 
 Debian has now accepted the wmaker-crm 0.95.0 tag
 (http://repo.or.cz/w/wmaker-crm.git/tree/d0a48d991490f3092e41b3f5e541913c0fd73da2)
 to be included into Debian unstable.
 
 Personally I would like to update our windowmaker (stable 0.92.0)
 package to the mentioned git tag (0.95.0). Our windowmaker-crm-git
 package will be updated to the latest development git snapshot as
 before.
 
 Any objections for this step?
 
 Daniel

windowmaker-0.95.0 is in [extra]. Feel free to test it (or not ;) ) and
file bug reports. I have tested it and it runs at the moment without
any errors.

Daniel


signature.asc
Description: PGP signature

[arch-dev-public] WindowMaker is back again

[Daniel Isenmann]

Hi,

I think everybody knows that WindowMaker development was stalled since
ages. It started again with the windowmaker-crm git repository. Now
windowmaker-crm is the most up-to-date source and is considered as the
official release. (Stated on the new website: http://windowmaker.org/)

Debian has now accepted the wmaker-crm 0.95.0 tag
(http://repo.or.cz/w/wmaker-crm.git/tree/d0a48d991490f3092e41b3f5e541913c0fd73da2)
to be included into Debian unstable.

Personally I would like to update our windowmaker (stable 0.92.0)
package to the mentioned git tag (0.95.0). Our windowmaker-crm-git
package will be updated to the latest development git snapshot as
before.

Any objections for this step?

Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Developer/TU key signing

[Daniel Isenmann]

On Fri, 25 Nov 2011 15:27:28 +0200
Ionut Biru ib...@archlinux.org wrote:

 Hi,
 
 my arch master key is available [1] with fingerprint 44D4 A033 AC14
 0143 9273  97D4 7EFD 567D 4C7E A887.
 
 Every packager please do:
 
 1) reply this email in the mailing list, include gerolde/sigurd
 username and sign your reply using your gpg key.
 2) name at least one package you already signed.
 
 [1] https://dev.archlinux.org/~ibiru/ionut_AT_master-key.archlinux.org
 
 

My username is daniel and signed package is monodevelop.

Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Developer / TU key signing, first master key available

[Daniel Isenmann]

On Sat, 19 Nov 2011 15:38:04 +0100
Thomas Bächler tho...@archlinux.org wrote:

 Hello developers / TUs,
 
 My Arch master key is available at [1] with fingerprint 6841 48BB 25B4
 9E98 6A49  44C5 5184 252D 824B 18E8.
 
 Every packager, please do the following:
 1) Reply to this email to tho...@master-key.archlinux.org and fully
 quote this email. Include your gerolde/sigurd username in the email.
 Sign your reply using your GPG key.
 2) Upload your public key (gpg --armor --export $KEYID) to your home
 directory on gerolde/sigurd under the name
 $HOME/arch-linux-packager-key. 3) Name at least one package in the
 repositories already signed with your key.
 
 Sadly, this process will only prove that you are in posession of the
 ssh key to upload packages into the repositories. I will contact you
 personally afterwards if I need further identification.
 
 Please note: there are be 5 master key holders (Allan, Dan, Pierre,
 Ionut, me), and you need at least 3 signatures on your key so your
 packages will be trusted by pacman.
 
 Regards
 Thomas
 
 [1]
 https://dev.archlinux.org/~thomas/thomas_AT_master-key.archlinux.org.asc
 

I have two signatures right now on my key. What about the others master
key holders? Are they going to send an email like you and Pierre did? 

Or should we send an email to them with the same procedure?

 Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Developer / TU key signing, first master key available

[Daniel Isenmann]

On Tue, 22 Nov 2011 19:23:30 +0100
Thomas Bächler tho...@archlinux.org wrote:

 Am 22.11.2011 19:04, schrieb Ionut Biru:
  I have two signatures right now on my key. What about the others
  master key holders? Are they going to send an email like you and
  Pierre did? 
 
  Or should we send an email to them with the same procedure?
 
   Daniel
  
  
  me and Dan are waiting the cards holders to arrive.
 
 And Allan is away right now. This process will not complete over
 night, but we're on it now.
 

I know that this process won't complete over night, I just was
wondering what the next steps are. Just reccieved the mail from you and
Pierre with the statement that you need at least 3 signatures to be
trusted by pacman and that's why I have asked. 

Just wanted to know what the status is and now I know it. ;)

Thanks...
Daniel


signature.asc
Description: PGP signature

Re: [arch-dev-public] Finalizing the package signing process

[Daniel Isenmann]

On Sun, 30 Oct 2011 14:12:20 +0100
Pierre Schmitz pie...@archlinux.de wrote:

 Hi all,
 
 it's about time to finalize our signing policy to get all our packages
 properly signed as soon as possible. Note that this is just about
 signing the package itself. How we will manage our keyring and sign
 that one using master keys is a different story.
 
 At first please have a look at
 https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages
 and let me know if there is anything wrong or unclear. I would like to
 present this little Howto to the TU so that community packages can be
 signed as well.
 
 To speed things up I'd like to let dbscripts enforce signed packages.
 This means that from now on no new packages can be uploaded that don't
 have a signature. We may give the TU a ew days mroe time as this will
 be new to them.
 
 If you just agree with all this send a +1.
 
 Greetings,
 
 Pierre
 

I'm building my packages exclusive on pkgbuild.com and there I can't
sign packages. If we do the switch in dbscripts then pkgbuild.com
should be ready to generate signed packages. As far as I know it isn't
possible yet, am I right?

Otherwise I would say +1, but for now -1.

Daniel

Re: [arch-dev-public] Finalizing the package signing process

[Daniel Isenmann]

On Sun, 30 Oct 2011 19:04:51 +0100
Giovanni Scafora giova...@archlinux.org wrote:

 Il 30/10/2011 18:56, Daniel Isenmann ha scritto:
  I'm building my packages exclusive on pkgbuild.com and there I can't
  sign packages. If we do the switch in dbscripts then pkgbuild.com
  should be ready to generate signed packages. As far as I know it
  isn't possible yet, am I right?
 
 You can build your packages on pkgbuild.com, then download them
 locally and sign them with gpg --detach-sign package.
 After, you have to send .sig files (i686 and x86_64) on pkgbuild,
 then execute extrapkg or similar command.
 
 

Downloading them locally isn't really a solution. Too low bandwidth and
most of the time I don't build the packages from home.

If dbscripts get updated without pkgbuild.com supports signing, then I
can't build packages.

Re: [arch-dev-public] sign packages on alderaan (was: Finalizing the package signing process)

[Daniel Isenmann]

On Sun, 30 Oct 2011 19:06:21 +0100
Florian Pritz bluew...@xinu.at wrote:

 On 30.10.2011 18:56, Daniel Isenmann wrote:
  I'm building my packages exclusive on pkgbuild.com and there I can't
  sign packages. If we do the switch in dbscripts then pkgbuild.com
  should be ready to generate signed packages. As far as I know it
  isn't possible yet, am I right?
 
 So far the only solution is to download the finished package, sign it
 locally using gpg --detach-sign file and then uploading the
 signature back to pkgbuild.com so commitpkg will find it.
 
 There has been some discussion [1] about remote signing for GPG, but I
 think they dropped the idea.
 
 [1]:
 http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042068.html

Kerrick Staley last comment [1] on this thread was that they will go
with the hash-signing implementation. But it seems that there is
nothing new on this topic.

[1]:
http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042078.html

Re: [arch-dev-public] Finalizing the package signing process

[Daniel Isenmann]

On Sun, 30 Oct 2011 21:32:25 +0100
Tom Gundersen t...@jklm.no wrote:

 On Sun, Oct 30, 2011 at 9:05 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  As it seems that there is no real solution here, I will try to do it
  like Florian and Giovanni said it. Downloading the package, sign it
  locally and upload the signature to pkguild again.
 
  Nevertheless we should find a solution to build signed packages on
  pkgbuild, otherwise we will loose our buildserver here, because I
  see this as a workaround and not as a solution.
 
 I don't think signing remotely is going to be possible, also I don't
 see the point of it. We anyway have to download the package in order
 to test it, so we wouldn't really gain anything.

Not all packages have to be tested, e.g. a large rebuild against a new
library version which you are sure that nothing is broken in your
pakage and only needs new linking against the new library.
That's only as an example.
 
 I use a script to download, sign and upload signature, then I test the
 package locally before pushing it to the repos.

Mind if you can provide the script. Such a helper script would help a
lot.

 Just my two cents.
 
 Cheers,
 
 Tom

Re: [arch-dev-public] Finalizing the package signing process

[Daniel Isenmann]

On Sun, 30 Oct 2011 21:58:35 +0100
Tom Gundersen t...@jklm.no wrote:

 On Sun, Oct 30, 2011 at 9:38 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  I don't think signing remotely is going to be possible, also I
  don't see the point of it. We anyway have to download the package
  in order to test it, so we wouldn't really gain anything.
 
  Not all packages have to be tested, e.g. a large rebuild against a
  new library version which you are sure that nothing is broken in
  your pakage and only needs new linking against the new library.
  That's only as an example.
 
 But surely you will eventually download and install it? That said, I
 guess there will be cases where it would be useful to not immediately
 have to download the package (even if I'm struggling to imagine atm).

Sure. I will do that. But mainly I build the packages not at home and
that's my main problem. But I will try the method with your small
script, thanks for that. 

 
  I use a script to download, sign and upload signature, then I test
  the package locally before pushing it to the repos.
 
  Mind if you can provide the script. Such a helper script would help
  a lot.
 
 Sure, it is based on something given to me by another dev on IRC
 (forgot who). Hopefully they won't sue me for copyright infringement
 ;-)
 
 It will leave the packages in /tmp for you to test, so you might want
 to remember to delete them afterwards.
 
 #!/bin/bash
 
 DIR=`mktemp -d /tmp/signpkg.${1}.X`
 pushd ${DIR}
 scp pkgbuild.com:svn-packages/$1/trunk/*.pkg.tar.xz .
 for i in *.pkg.tar.xz; do
 #  gpg --detach-sign --use-agent -u $KEY $i
   gpg --detach-sign --use-agent $i
 done
 scp *.pkg.tar.xz.sig pkgbuild.com:svn-packages/$1/trunk/
 popd

Thanks for that...

Daniel

Re: [arch-dev-public] [signoff] rp-pppoe-3.10-6

[Daniel Isenmann]

Am 04.05.2011 06:13, schrieb Jan Steffens:

On Mon, Apr 18, 2011 at 9:14 AM, Daniel Isenmanndaniel.isenm...@gmx.de  wrote:

I have fixed:

FS#22481 - [rp-pppoe] remove from base group
FS#20925 - [rp-pppoe] pppoe-server has wrong hardcoded path to pppoe-plugin

Please signoff i686 and x86_64. I can't test it, because I don't use it.

  Daniel


Signoff i686.

I have moved it. Thanks for signoffs.

Daniel

Re: [arch-dev-public] [signoff] rp-pppoe-3.10-6

[Daniel Isenmann]

No signoffs? No one who use rp-pppoe?

Am 18.04.2011 09:14, schrieb Daniel Isenmann:

I have fixed:

FS#22481 - [rp-pppoe] remove from base group
FS#20925 - [rp-pppoe] pppoe-server has wrong hardcoded path to 
pppoe-plugin


Please signoff i686 and x86_64. I can't test it, because I don't use it.

 Daniel

[arch-dev-public] [signoff] rp-pppoe-3.10-6

[Daniel Isenmann]

I have fixed:

FS#22481 - [rp-pppoe] remove from base group
FS#20925 - [rp-pppoe] pppoe-server has wrong hardcoded path to pppoe-plugin

Please signoff i686 and x86_64. I can't test it, because I don't use it.

 Daniel

Re: [arch-dev-public] Temporarily removed nvidia legacy driver

[Daniel Isenmann]

Am 14.04.2011 07:58, schrieb Pierre Schmitz:

On Wed, 13 Apr 2011 16:54:40 +0100, Pierre Schmitz wrote:

Just to let you know: I have removed the nvidia-173xx driver packages
from [extra]. They wont work with current xorg-server anyway. Once
nvidia releases a new driver these can be readded easily. Keeping a
package that cannot work is kind of pointless.

Greetings,

Pierre

I also had to remove the nvidia-96xx packages we still had. This means
if you want to use the proprietary driver you'll need at least a Geforce
6. There is nothing we can do about this.

Greetings,

Pierre


You should post this on the frontpage. I think that lots of users use 
those drivers and they will be surprised when it won't work after the 
update. Add a recommendation to use the nouveau-driver instead as long 
as there are no new driver from nvidia. Maybe some users stay with the 
nouveau driver after the switch.


 Daniel

[arch-dev-public] Removing network utilities from base group?

[Daniel Isenmann]

Hi,

I have a feature request (https://bugs.archlinux.org/task/22481) since 
January which stated that rp-pppoe should be removed from the base 
group. Described in the details he stated that every network package 
should be removed from the base group and should only be in core.


I'm not really have a opinion to that topic, so what do you think about 
it? For me we can leave it as it is and do nothing at this topic, then I 
will close this feature request as won't implement.


 -Daniel

Re: [arch-dev-public] [signoff] kernel26-2.6.38-1

[Daniel Isenmann]

On Wed, 16 Mar 2011 20:27:44 +0100
Tobias Powalowski t.p...@gmx.de wrote:

 Hi guys,
 please signoff 2.6.38 series for both arches.
 
 Upstream
 changes:
 http://kernelnewbies.org/LinuxChanges
 
 Features included:
 - kernel image is now xz compressed
 - NUMA is enabled on x86_64
 - AUTOSCHED (aka the wonder patch) is enabled
 - aufs2.1 latest snapshot 
 
 
 greetings
 tpowa

Signoff x86_64.

Re: [arch-dev-public] Dropping Oracle OpenOffice

[Daniel Isenmann]

On Mon, 7 Mar 2011 18:45:34 +0100
Andreas Radke a.ra...@arcor.de wrote:

 LibreOffice has recently proved to be a solid replacement for Oracle
 OpenOffice. I'm about to drop all Oracle OOo packages from our repos.
 
 First my time is limited. I've asked so many times for help in the
 Office packaging area and nobody stepped in.
 
 Then there's the poor distribution support Oracle spends on the
 distributions. They almost do not care about custom distribution
 builds and their interest. They break the build against system libs
 every now and then and it takes ages to contact the relevant devs to
 fix their bugs. Development is only driven by the profit interests of
 Oracle... You can put in here all the arguments the Document
 foundation has given at its birth.
 
 So don't expect any efforts to fix bugs in Oracle packages anymore. As
 soon as they will break due to a .so name bump or something like this
 I'll remove all the packages from our repos if nobody else is willing
 to maintain them.
 
 
 Any objections to add 
 replaces=('openoffice-base')  to the next LibO pkg?

+1 from me.

 Daniel

Re: [arch-dev-public] [signoff] man-db 2.5.8-1

[Daniel Isenmann]

On Tue, 16 Nov 2010 20:27:04 +0100
Andreas Radke a.ra...@arcor.de wrote:

 New upstream release. Please signoff.
 
 Anybody ever heard of the mentioned libpipeline? It seems so far it
 hasn't been packaged in any form for Arch. I'll have to bring this in
 when 2.6.0 comes out.

Signoff x86_64

Re: [arch-dev-public] [signoff] man-db 2.5.9-1

[Daniel Isenmann]

On Wed, 17 Nov 2010 20:11:18 +0100
Andreas Radke a.ra...@arcor.de wrote:

 A quick fix release is out. Please signoff version 2.5.9!
 
 -Andy

Works, too. Signoff x86_64

Re: [arch-dev-public] Doing a rebuild of [core]?

[Daniel Isenmann]

Am 18.11.2010 06:52, schrieb Andreas Radke:

Am Thu, 18 Nov 2010 14:16:34 +1000
schrieb Allan McRaeal...@archlinux.org:


Hi,

I was thinking of doing a fairly large rebuild of packages in [core]
for the following reasons:

   - The toolchain is quite good at the moment and many packages have
not been built in a long time so could use a refresher build to take
advantage of what the newer toolchain offers (~15 packages are  1
year old).  I expect a toolchain update to happen in the next few
weeks so this is a good time.

What update do you expect? Usually a rebuild is useful to catch
up latest major gcc improvements. Gcc4.6 is still in an early
stage. Maybe we should delay it until the gcc4.6 release.

The toolchain improvements over the last 2 years were of minor
advantages. So I don't expect major performance improvements.

Getting the packages into xz compression format and pkg pool would be
nice though.

One concern for a rebuild right now: most packagers allowed for
pushing packages into core haven't been much online lately. Not sure
if they can spend that much time. Sadly makeworld has died. But I
remember Daniel made such a rebuild script locally (was at gcc4.3
release?).


That's right, I made such a rebuild script. But I'm not really sure if I 
have it any longer. Have to check it at home. It was a hackish bash 
script which increased the pkgrel variable and rebuild the package, 
that's all.


I'm not that close to the toolchain changes and its improvements, so if 
you think it's time for that go ahead. :)


 -Daniel

[arch-dev-public] Planet Arch Linux and new theme?

[Daniel Isenmann]

 Hi,

I have seen that our Planet Arch Linux (http://planet.archlinux.org) 
doesn't have the new website design.

Are there any plans to change the theme?

Cheers,
Daniel

Re: [arch-dev-public] Warning: MESA 7.9 going to testing

[Daniel Isenmann]

On Sat, 9 Oct 2010 09:55:43 +0200
Andreas Radke a.ra...@arcor.de wrote:

 I'm working on the new MESA release today. Please don't -Syu until all
 3D drivers have been rebuild properly. If you have trouble with your
 card catch me in out IRC channels.
 
 -Andy

I discoverd today that fusion-icon won't run with the new update,
because of the missing glxinfo. This program is now located under
mesa-demos. fusion-icon complains about the missing glxinfo and won't
start, so install mesa-demos manually at the moment.

@fusion-icon maintainer:
Should be added as a depend to the package or at least a note should be
posted to that.

 -Daniel

Re: [arch-dev-public] [aur-general] Warning: MESA 7.9 going to testing

[Daniel Isenmann]

On Tue, 12 Oct 2010 21:01:24 +0200
Ronald van Haren pre...@gmail.com wrote:

 On Tue, Oct 12, 2010 at 8:20 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  On Sat, 9 Oct 2010 09:55:43 +0200
  Andreas Radke a.ra...@arcor.de wrote:
 
  I'm working on the new MESA release today. Please don't -Syu until
  all 3D drivers have been rebuild properly. If you have trouble
  with your card catch me in out IRC channels.
 
  -Andy
 
  I discoverd today that fusion-icon won't run with the new update,
  because of the missing glxinfo. This program is now located under
  mesa-demos. fusion-icon complains about the missing glxinfo and
  won't start, so install mesa-demos manually at the moment.
 
  @fusion-icon maintainer:
  Should be added as a depend to the package or at least a note
  should be posted to that.
 
   -Daniel
 
 
 please file a bug report next time so it does not get lost.
 
 On a related note, it can't be fixed before the python2 move as
 otherwise this fix will move to community before mesa moves to extra
 with the python2 move.
 
 Ronald

Next time I will file a bug report. That it must wait for the python2
move that's no problem.
The main reason for posting this mail was that it was not mentioned
that glxinfo was separated into an extra package. The notice for you
was just a side note.

Daniel

Re: [arch-dev-public] new pkg for extra: LXDM

[Daniel Isenmann]

On Sun, 10 Oct 2010 13:26:19 +0200
Andreas Radke a.ra...@arcor.de wrote:

 LXDM had a nice stable release 0.3.0 a few weeks ago and is ready to
 use. It's the best light weight alternative we have next to gdm/kdm
 and slim/xdm.
 
 I know about Jürgens ask for help on lxde packages but I'd like to
 maintain lxdm in extra independent from lxde as an option for Xfce
 users.
 
 Any objections?
 
 -Andy

It's very fast and slim with no need to install any lxdm package, as
you said, perfect for any small DEs without a login manager.

+1 from me.

Daniel

Re: [arch-dev-public] [signoff] bzip2-1.0.6-1

[Daniel Isenmann]

On Tue, 21 Sep 2010 15:31:17 +0300
Ionuț Bîru ib...@archlinux.org wrote:

 Hi,
 fixing https://bugs.archlinux.org/task/20901
 
 Changelog:
 
 Version 1.0.6 removes a potential security vulnerability,
 CVE-2010-0405, so all users are recommended to upgrade immediately.
 

Signoff x86_64

Re: [arch-dev-public] [signoff] kernel26 2.6.35.5-1

[Daniel Isenmann]

On Tue, 21 Sep 2010 15:44:52 +0200
Tobias Powalowski t.p...@gmx.de wrote:

 Latest kernel is in testing,
 please signoff for both arches.
 
 greetings
 tpowa

signoff x86_64. Booted and works fine.

[arch-dev-public] Back from vacation

[Daniel Isenmann]

Hi,

I'm back from 3 weeks vacation. It was awesome...Canada (especially BC
and Alberta) is a great country.

I'm fighting through ~4500 mails and against my jetlag, so after I have
win the fights I will be back at work.

Cheers,
 Daniel

[arch-dev-public] Mono release 2.8 with major changes is coming (soon)

[Daniel Isenmann]

 Hi,

I know that many of you don't use mono, but anyway a new major release 
is coming with some changes which may affect packages which depends on mono.


I have read the changelog draft of mono 2.8 (you can find it here: 
http://mono-project.com/Release_Notes_Mono_2.8) and there are some 
significant changes, like the removing of .NET 1.1 profile. Normally 
that shouldn't be a problem, because most applications are using .NET 
2.0 profile and not the old 1.1, but who knows if some applications 
using the old one. If an application uses the old 1.1 profile it will be 
automatically switched to the 2.0 profile and a warning should appear.
Seven old and deprecated libraries will be removed from the mono 
release, to be precisly:

 * ByteFX.Data
 * Mono.Data
 * Microsoft.JScript and Microsoft.Vsa
 * FirebirdSql.Data.Firebird
 * Mono.Data.SybaseClient
 * Mono.Data.SqliteClient

Mono 2.8 will ship a new garbage collector (SGen), I will activate it by 
default. You can change that by setting an environment variable 
(information will follow at release day). The new release includes 4 new 
libraries from Microsoft directly, they are licensed und MS-PL or Apache 
2 Open Source Licenses, so that shouldn't be a problem for us.


Another critical change will be the ThreadPool behavior. This has been 
changed and will potentially break existing applications.


I have written in my Away email that you can update my packages, but 
please DO NOT UPDATE the mono packages during my vacation. I will update 
mono after my vacation (if it will be released in that time). As always 
I try to do the update as smooth as possible, but this time there are 
some real big changes in the new release which may not allow this.


Sorry for the long email and such specific information about the new 
mono release, but I think it's necessary for such a major release.


 -Daniel

Re: [arch-dev-public] Mono release 2.8 with major changes is coming (soon)

[Daniel Isenmann]

 Am 04.08.2010 16:19, schrieb Eric Bélanger:

On Wed, Aug 4, 2010 at 2:28 AM, Daniel Isenmanndaniel.isenm...@gmx.de  wrote:

  Hi,

I know that many of you don't use mono, but anyway a new major release is
coming with some changes which may affect packages which depends on mono.

I have read the changelog draft of mono 2.8 (you can find it here:
http://mono-project.com/Release_Notes_Mono_2.8) and there are some
significant changes, like the removing of .NET 1.1 profile. Normally that
shouldn't be a problem, because most applications are using .NET 2.0 profile
and not the old 1.1, but who knows if some applications using the old one.
If an application uses the old 1.1 profile it will be automatically switched
to the 2.0 profile and a warning should appear.
Seven old and deprecated libraries will be removed from the mono release, to
be precisly:
  * ByteFX.Data
  * Mono.Data
  * Microsoft.JScript and Microsoft.Vsa
  * FirebirdSql.Data.Firebird
  * Mono.Data.SybaseClient
  * Mono.Data.SqliteClient

Mono 2.8 will ship a new garbage collector (SGen), I will activate it by
default. You can change that by setting an environment variable (information
will follow at release day). The new release includes 4 new libraries from
Microsoft directly, they are licensed und MS-PL or Apache 2 Open Source
Licenses, so that shouldn't be a problem for us.

Another critical change will be the ThreadPool behavior. This has been
changed and will potentially break existing applications.

I have written in my Away email that you can update my packages, but
please DO NOT UPDATE the mono packages during my vacation. I will update
mono after my vacation (if it will be released in that time). As always I
try to do the update as smooth as possible, but this time there are some
real big changes in the new release which may not allow this.

Sorry for the long email and such specific information about the new mono
release, but I think it's necessary for such a major release.

  -Daniel


It might be a bit off-topic but I'm wondering if, with that new
release of mono, you'll add moonlight to extra. IIRC, when we removed
the moonlight package from community a while ago because it had to be
rebuilt and that version wasn't building anymore, you mentionned that
eventually you'll add moonlight to extra. Is it still your intention
or am I remembering incorrectly?

Thanks,
Eric



Your are right, this is still my intention. But the actual moonlight 
sourcecode need some files from mono which are only present during 
compilation time. Furthermore the old and stable release of moonlight 
doesn't compile with our mono, but the latest snapshot doesn't compile 
with our mono, too. They need newer version of mono. The moonlight 
developers are aware of that and it should be fixed after moonlight 3.0 
final is released and depend on the current mono release then. So, the 
first moonlight version which will be added to [extra] maybe will be 
moonlight 3.0.

[arch-dev-public] Away Aug 9 - Aug 31

[Daniel Isenmann]

 Time for vacation, for very long vacation. :)
I will be in Canada, more precisely travelling around in Alberta and BC.

I won't have internet access during that time, so I'm not able to read 
mails or fix/update packages. Feel free to fix or update my packages.


 -Daniel

Re: [arch-dev-public] Away Aug 9 - Aug 31

[Daniel Isenmann]

 Am 03.08.2010 13:59, schrieb Dieter Plaetinck:

On Tue, 3 Aug 2010 14:53:45 +0300
Roman Kyrylychroman.kyryl...@gmail.com  wrote:


On Tue, Aug 3, 2010 at 13:15, Daniel Isenmann
daniel.isenm...@gmx.de  wrote:

  Time for vacation, for very long vacation. :)
I will be in Canada, more precisely travelling around in Alberta
and BC.

I won't have internet access during that time, so I'm not able to
read mails or fix/update packages. Feel free to fix or update my
packages.

Have a nice time there!


Cool shit.  You can go meet up with Jason (he lives in BC).
Looking forward to your pictures.  I'm sure you'll make many.

Dieter


Yeah, I will take lot of pictures. That's sure! I will post my best 
pictures at my photo page (as usual).


Daniel

Re: [arch-dev-public] [signoff] kernel26 2.6.33.3-1

[Daniel Isenmann]

On Mon, 26 Apr 2010 19:45:36 +0200
Thomas Bächler tho...@archlinux.org wrote:

 This is an upstream kernel release, including security fixes. Packages
 will enter testing within the next hour.
 
 We had a gcc 4.4 - 4.5 version bump, so the external modules are
 still compiled with 4.4, while the kernel is compiled with 4.5. If any
 external modules break (usual candidates are nvidia and aufs2), we
 will have to rebuild them with 4.5 as well.
 
 Please test this update thoroughly and sign off. Please provide
 feedback about the state of our nvidia and aufs2 (or other external)
 builds, so we know whether we require a rebuild.
 

Signoff x86_64. Works with nvidia without problems...

[arch-dev-public] Changed GNUstep directory in new windowmaker package

[Daniel Isenmann]

Hi,

today I have released a new release of the windowmaker package. The
important change is the GNUstep directory. I have changed this
to /usr/lib/GNUstep. It was requested as a bug report
(http://bugs.archlinux.org/task/15301) and it’s now equal to Debian’s
GNUstep directory location.

That means, you have to change the directory for the WPrefs.App which
has now the new location. All other things should be run without
problems. If you have older GNUstep applications, you have to recompile
them with the new location if they way located in the old GNUstep
directory.

 -Daniel

Re: [arch-dev-public] kernel 2.6.33-1

[Daniel Isenmann]

On Sat, 27 Feb 2010 15:46:16 +0100
Tobias Powalowski t.p...@gmx.de wrote:

 Hi guys,
 kernel 2.6.33 first test run ...
 
 Upstream changes:
 http://kernelnewbies.org/LinuxChanges
 
 Arch Linux bugfixes/feature requests:
 http://bugs.archlinux.org/task/18249 # added HPET 
 http://bugs.archlinux.org/task/17970 # added CONFIG_USB_GSPCA_PAC7302
 http://bugs.archlinux.org/task/17791 # added UTS_NAMESPACE
 http://bugs.archlinux.org/task/17756 # added CONFIG_FRAME_POINTER for
 WCHAN http://bugs.archlinux.org/task/16715 # added Linux Container
 support
 - added jfs and reiserfs statistics
 
 Arch Linux changes:
 - changed radeon kms enabled by default
 - merged ext2/ext3 support into ext4 module
 - nouveau module is still provided as out-of-tree module, it's more
 up to date.
 
 Broken binary modules:
 - lirc,fcpcmcia,madwifi,tiacx though no fix available yet.
 
 Needs to rebuild:
 - 686 modem binary modules
 
 Enjoy have fun and give me feedback,
 greetings
 tpowa

I have no special setup. Kernel is running fine, only new message in
dmesg is: 

EXT4-fs (sdb1): Ignoring delalloc option - requested data journaling
mode 
EXT4-fs (sdb1): mounted filesystem with journalled data mode

I can't remember that this message was there before. The partition
is an ext3 partition mounted as ext4.

Apart from those two messages is everything fine.

 -Daniel

[arch-dev-public] [signoff] rp-pppoe-3.10-3

[Daniel Isenmann]

Hi,

this is a small fix for the bug reported here:
http://bbs.archlinux.org/viewtopic.php?pid=699763

Now, you have to set explicit the plugin path to the kernel mode
plugin if you want to use it. So, it's up to you if you need it or
not and it won't be set anymore as default, because it generated too
much errors for some users.

Please test it and signoff.

 -Daniel

Re: [arch-dev-public] wesnoth issue with png

[Daniel Isenmann]

 Original-Nachricht 
 Datum: Fri, 22 Jan 2010 11:10:02 +0100
 Von: Tobias Powalowski t.p...@gmx.de
 An: Public mailing list for Arch Linux development 
 arch-dev-public@archlinux.org
 Betreff: [arch-dev-public] wesnoth issue with png

 Hi guys need some help on wesnoth,
 tools/exploder_utils.cpp: In function 'void save_image(surface, const 
 std::string)':
 tools/exploder_utils.cpp:177: error: 'png_voidp_NULL' was not declared in
 this 
 scope
 tools/exploder_utils.cpp:178: error: 'png_error_ptr_NULL' was not declared
 in 
 this scope
 make[2]: *** [tools/exploder_utils.o] Error 1
 
 affected codepart:
   png_struct* png_ptr = png_create_write_struct
   (PNG_LIBPNG_VER_STRING, (png_voidp)png_voidp_NULL,
png_error_ptr_NULL, png_error_ptr_NULL);
 
 
 snip from changelog of 1.4 libpng
b. We removed the typecasted NULL definitions such as
 
   #define png_voidp_NULL(png_voidp)NULL
 
   If you used these in your application, just use NULL instead.
 
 so what should i add?
 
 thanks
 greetings
 tpowa


Just what the changelog say, use NULL. So change the method to:

png_struct* png_ptr = png_create_write_struct
(PNG_LIBPNG_VER_STRING, (png_voidp)NULL,
 png_error_ptr_NULL, png_error_ptr_NULL);

Maybe you have to change the png_error_ptr_NULL to NULL also.


 Daniel

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: [arch-dev-public] wesnoth issue with png

[Daniel Isenmann]

 Original-Nachricht 
 Datum: Fri, 22 Jan 2010 11:18:35 +0100
 Von: Daniel Isenmann daniel.isenm...@gmx.de
 An: Public mailing list for Arch Linux development 
 arch-dev-public@archlinux.org
 Betreff: Re: [arch-dev-public] wesnoth issue with png

 
  Original-Nachricht 
  Datum: Fri, 22 Jan 2010 11:10:02 +0100
  Von: Tobias Powalowski t.p...@gmx.de
  An: Public mailing list for Arch Linux development
 arch-dev-public@archlinux.org
  Betreff: [arch-dev-public] wesnoth issue with png
 
  Hi guys need some help on wesnoth,
  tools/exploder_utils.cpp: In function 'void save_image(surface, const 
  std::string)':
  tools/exploder_utils.cpp:177: error: 'png_voidp_NULL' was not declared
 in
  this 
  scope
  tools/exploder_utils.cpp:178: error: 'png_error_ptr_NULL' was not
 declared
  in 
  this scope
  make[2]: *** [tools/exploder_utils.o] Error 1
  
  affected codepart:
  png_struct* png_ptr = png_create_write_struct
  (PNG_LIBPNG_VER_STRING, (png_voidp)png_voidp_NULL,
   png_error_ptr_NULL, png_error_ptr_NULL);
  
  
  snip from changelog of 1.4 libpng
 b. We removed the typecasted NULL definitions such as
  
#define png_voidp_NULL(png_voidp)NULL
  
If you used these in your application, just use NULL instead.
  
  so what should i add?
  
  thanks
  greetings
  tpowa
 
 
 Just what the changelog say, use NULL. So change the method to:
 
 png_struct* png_ptr = png_create_write_struct
   (PNG_LIBPNG_VER_STRING, (png_voidp)NULL,
png_error_ptr_NULL, png_error_ptr_NULL);
 
 Maybe you have to change the png_error_ptr_NULL to NULL also.
 
 
  Daniel

Was there something mentioned about the png_error_ptr_NULL in the changelog? 
Because this is also affected. I have overseen the error message from the 
compiler for it.


-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: [arch-dev-public] wesnoth issue with png

[Daniel Isenmann]

 Original-Nachricht 
 Datum: Fri, 22 Jan 2010 11:27:16 +0100
 Von: Tobias Powalowski t.p...@gmx.de
 An: Public mailing list for Arch Linux development 
 arch-dev-public@archlinux.org
 Betreff: Re: [arch-dev-public] wesnoth issue with png

 Am Freitag 22 Januar 2010 schrieb Daniel Isenmann:
   Original-Nachricht 
  
   Datum: Fri, 22 Jan 2010 11:18:35 +0100
   Von: Daniel Isenmann daniel.isenm...@gmx.de
   An: Public mailing list for Arch Linux development
   arch-dev-public@archlinux.org Betreff: Re: [arch-dev-public] wesnoth
   issue with png
  
  
    Original-Nachricht 
  
Datum: Fri, 22 Jan 2010 11:10:02 +0100
Von: Tobias Powalowski t.p...@gmx.de
An: Public mailing list for Arch Linux development
  
   arch-dev-public@archlinux.org
  
Betreff: [arch-dev-public] wesnoth issue with png
   
Hi guys need some help on wesnoth,
tools/exploder_utils.cpp: In function 'void save_image(surface,
 const
std::string)':
tools/exploder_utils.cpp:177: error: 'png_voidp_NULL' was not
 declared
  
   in
  
this
scope
tools/exploder_utils.cpp:178: error: 'png_error_ptr_NULL' was not
  
   declared
  
in
this scope
make[2]: *** [tools/exploder_utils.o] Error 1
   
affected codepart:
png_struct* png_ptr = png_create_write_struct
(PNG_LIBPNG_VER_STRING, (png_voidp)png_voidp_NULL,
 png_error_ptr_NULL, png_error_ptr_NULL);
   
   
snip from changelog of 1.4 libpng
   b. We removed the typecasted NULL definitions such as
   
  #define png_voidp_NULL(png_voidp)NULL
   
  If you used these in your application, just use NULL instead.
   
so what should i add?
   
thanks
greetings
tpowa
  
   Just what the changelog say, use NULL. So change the method to:
  
   png_struct* png_ptr = png_create_write_struct
 (PNG_LIBPNG_VER_STRING, (png_voidp)NULL,
  png_error_ptr_NULL, png_error_ptr_NULL);
  
   Maybe you have to change the png_error_ptr_NULL to NULL also.
  
  
Daniel
  
  Was there something mentioned about the png_error_ptr_NULL in the
   changelog? Because this is also affected. I have overseen the error
   message from the compiler for it.
  
 no, no mention about it setting to NULL makes it compile though.

Yeah, that's for sure. Both png_error_ptr_NULL are pointers and pointers can 
be NULL. So compilation works. But if they are something special (which I don't 
believe, because they have NULL in their names) it can crash.

I don't think it's a good idea to set both just to NULL. I can have a closer 
look into the sourcecode this evening at home and maybe can give you the right 
answer.

 Daniel
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

[arch-dev-public] [signoff] wicd-1.7.0-1

[Daniel Isenmann]

Hi,

there is a new version of wicd in [testing]. In the past there were
always problems in upgrading wicd, so I have decided to put it in
[testing] first. Please test it and give me some signoffs.

Big changelog:

1.7.0:
Changes for Packagers:
- Wicd now supports a -k option, which should be run by the
init script when the daemon is stopped to release the DHCP lease but
should not be run on a restart of the daemon.
- The ability has been added to split Wicd's components into
multiple directories. Use --gtk, --cli, --curses, and --daemon to
  setup.py configure to specify the locations of the respective
  components.
- The preferred way to run the GTK UI is now to use wicd-gtk,
not wicd-client. wicd-gtk is a new addition to 1.7 that will never
  run wicd-curses. wicd-client will automatically decide to run
  wicd-curses if there is no X session available.

Major Changes:
- Connection information is available by right clicking the
tray icon
- Can set the hostname per network for all DHCP clients
- urwid 0.9.9 is now supported
- Added wicd-cli, a command line interface for use in scripts
- Global scripts are now passed parameters specifying the
network

Minor Changes:
- Support for only displaying notifications using -o to
wicd-client
- Reconnecting now works when measuring signal strength in dBm
- ESSIDs made of numbers now work properly
- All valid wpa_supplicant drivers are now displayed
- Wired network is now displayed while scanning wireless
networks
- Added wicd-gtk, a command to always and only run the GTK UI
- Marked ioctl backend not supported
- Use dhcpcd-bin on Debian instead of dhcpcd script



 Daniel

[arch-dev-public] Merging dhclient and dhcp package

[Daniel Isenmann]

Hi,

I don't know why this idea didn't came earlier to my mind, but the
dhclient and dhcp package share the same source file. Now that pacman
supports splitted packages this can be merged into one PKGBUILD and
build both packages at once. This should be really easier than
maintaining both packages from differents maintainer like at the moment.

Any objections for doing this?

 Daniel

Re: [arch-dev-public] Merging dhclient and dhcp package

[Daniel Isenmann]

On Sun, 17 Jan 2010 12:55:14 +0100
Jan de Groot j...@jgc.homeip.net wrote:

 On Sun, 2010-01-17 at 12:23 +0100, Daniel Isenmann wrote:
  Hi,
  
  I don't know why this idea didn't came earlier to my mind, but the
  dhclient and dhcp package share the same source file. Now that
  pacman supports splitted packages this can be merged into one
  PKGBUILD and build both packages at once. This should be really
  easier than maintaining both packages from differents maintainer
  like at the moment.
  
  Any objections for doing this?
  
   Daniel
 
 Do it.

I have made the PKGBUILD for the splitted package. Can I just upload
the packages with extrapkg in the dhcp trunk directory? What happens to
the existing dhclient package in the SVN, must I delete it before?

 Daniel

Re: [arch-dev-public] Merging dhclient and dhcp package

[Daniel Isenmann]

On Sun, 17 Jan 2010 13:42:36 +0100
Jan de Groot j...@jgc.homeip.net wrote:

 On Sun, 2010-01-17 at 13:33 +0100, Daniel Isenmann wrote:
  
  I have made the PKGBUILD for the splitted package. Can I just upload
  the packages with extrapkg in the dhcp trunk directory? What
  happens to the existing dhclient package in the SVN, must I delete
  it before?
  
   Daniel
 
 The scripts will overwrite the entry in database and repositories. I
 don't know if it cleans up svn for you, but in case it doesn't, you
 can just svn rm the old dhclient package.

Merged and all committed to SVN. It hasn't delete the old directory,
but I will delete it on my own as you said it.

 Daniel

Re: [arch-dev-public] Merging dhclient and dhcp package

[Daniel Isenmann]

On Sun, 17 Jan 2010 16:02:15 +0100
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 On Sun, 17 Jan 2010 13:42:36 +0100
 Jan de Groot j...@jgc.homeip.net wrote:
 
  On Sun, 2010-01-17 at 13:33 +0100, Daniel Isenmann wrote:
   
   I have made the PKGBUILD for the splitted package. Can I just
   upload the packages with extrapkg in the dhcp trunk directory?
   What happens to the existing dhclient package in the SVN, must I
   delete it before?
   
Daniel
  
  The scripts will overwrite the entry in database and repositories. I
  don't know if it cleans up svn for you, but in case it doesn't, you
  can just svn rm the old dhclient package.
 
 Merged and all committed to SVN. It hasn't delete the old directory,
 but I will delete it on my own as you said it.
 
  Daniel

I have some problems in deleting the old dhclient svn directory. Can
someone please delete the dhclient svn directory? Not the package in
the package database, only the SVN directory with svn rm. 

Thanks,
 Daniel

Re: [arch-dev-public] Merging dhclient and dhcp package

[Daniel Isenmann]

On Sun, 17 Jan 2010 16:17:23 +0100
Andrea Scarpino and...@archlinux.org wrote:

 On 17/01/2010, Daniel Isenmann daniel.isenm...@gmx.de wrote:
  I have some problems in deleting the old dhclient svn directory. Can
  someone please delete the dhclient svn directory? Not the package in
  the package database, only the SVN directory with svn rm.
 Done.

Thanks...

 
 ...and like ever I committed my changes...uff I hate svn.
 

Do it like Ionut said it, then everything will be fine. ;)

Re: [arch-dev-public] [signoff] rp-pppoe-3.10-2

[Daniel Isenmann]

On Tue, 12 Jan 2010 19:58:46 +0100
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 On Sun, 10 Jan 2010 13:49:50 +0100
 Daniel Isenmann daniel.isenm...@gmx.de wrote:
 
  On Wed, 6 Jan 2010 14:20:32 +0100
  Daniel Isenmann daniel.isenm...@gmx.de wrote:
  
   Hi,
   
   this is just a small fix for FS#13876 -[rp-pppoe] package: .so
   file in /etc (http://bugs.archlinux.org/task/13876). 
   The kernel-mode plugin is now under /usr/lib/rp-pppoe/rp-pppoe.so
   and the initial config file /etc/ppp/pppoe.conf has the new path
   included. Existing config file must be changed to the new path.
   
   I can't test it, so please test if everything is working and
   signoff.
   
Daniel
  
  Anyone?
  
   Daniel
 
 Ok, I will move this later this evening or tomorrow evening. There are
 no issues reported at the moment, so it runs for those who use it.
 
 Daniel

Moved.

Daniel

Re: [arch-dev-public] [signoff] rp-pppoe-3.10-2

[Daniel Isenmann]

On Sun, 10 Jan 2010 13:49:50 +0100
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 On Wed, 6 Jan 2010 14:20:32 +0100
 Daniel Isenmann daniel.isenm...@gmx.de wrote:
 
  Hi,
  
  this is just a small fix for FS#13876 -[rp-pppoe] package: .so file
  in /etc (http://bugs.archlinux.org/task/13876). 
  The kernel-mode plugin is now under /usr/lib/rp-pppoe/rp-pppoe.so
  and the initial config file /etc/ppp/pppoe.conf has the new path
  included. Existing config file must be changed to the new path.
  
  I can't test it, so please test if everything is working and
  signoff.
  
   Daniel
 
 Anyone?
 
  Daniel

Ok, I will move this later this evening or tomorrow evening. There are
no issues reported at the moment, so it runs for those who use it.

Daniel

Re: [arch-dev-public] [signoff] rp-pppoe-3.10-2

[Daniel Isenmann]

On Wed, 6 Jan 2010 14:20:32 +0100
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 Hi,
 
 this is just a small fix for FS#13876 -[rp-pppoe] package: .so file
 in /etc (http://bugs.archlinux.org/task/13876). 
 The kernel-mode plugin is now under /usr/lib/rp-pppoe/rp-pppoe.so and
 the initial config file /etc/ppp/pppoe.conf has the new path included.
 Existing config file must be changed to the new path.
 
 I can't test it, so please test if everything is working and signoff.
 
  Daniel

Anyone?

 Daniel

[arch-dev-public] [signoff] rp-pppoe-3.10-2

[Daniel Isenmann]

Hi,

this is just a small fix for FS#13876 -[rp-pppoe] package: .so file
in /etc (http://bugs.archlinux.org/task/13876). 
The kernel-mode plugin is now under /usr/lib/rp-pppoe/rp-pppoe.so and
the initial config file /etc/ppp/pppoe.conf has the new path included.
Existing config file must be changed to the new path.

I can't test it, so please test if everything is working and signoff.

 Daniel

[arch-dev-public] Moonlight in Arch Linux

[Daniel Isenmann]

Hi,

I know that this topic was discussed in January this year and we
decided to put it to AUR and if it have enough votes to [community].

For all new developers, here is the discussion from January:
http://mailman.archlinux.org/pipermail/arch-dev-public/2009-January/010029.html

Now it's in community, but it's outdated and which is the real problem,
you must build it with a fresh built and installed mono during
compilation time. It depends very close to mono and therefor I would
like to bring it to [extra], to maintain it with the rest of the mono
stack which I already do.

Also a bug report was posted because of this issue:
http://bugs.archlinux.org/task/17573

The maintainer in community seems not be active anymore (Timm Preetz)
and moonlight is orphan.

Any objections from your side?

Cheers,
 Daniel

Re: [arch-dev-public] Moonlight in Arch Linux

[Daniel Isenmann]

On Tue, 22 Dec 2009 03:29:14 -0800
Giovanni Scafora giova...@archlinux.org wrote:

 2009/12/22, Daniel Isenmann daniel.isenm...@gmx.de:
   Any objections from your side?
 
 +1 to bring it to [extra].
 I also can help you, upgrading it if needed.
 
 

Thanks, but I have already a running version of moonlight 2.0
So, that's no problem.

Re: [arch-dev-public] Moonlight in Arch Linux

[Daniel Isenmann]

On Tue, 22 Dec 2009 18:28:01 +0100
Pierre Schmitz pie...@archlinux.de wrote:

 On Tue, 22 Dec 2009 11:12:30 -0600, Aaron Griffin
 aaronmgrif...@gmail.com
 wrote:
  However, isn't there some legal issues with Moonlight? I saw
  recently that Microsoft pledged not to sue Moonlight users
 
  There are no issues as software patents do not exist for us. :P
  
  http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
 
 Moonlight is licensed under the GPL. Who cares what patent problems it
 might have in the US?
 
 Of course this plugin is quite useless anyway (only works with
 firefox and those few sites using silverlight only seem to support
 the microsoft implementation). But I am fine with it if Daniel wants
 to maintain it.
 

Pierre is right on this point. It's distributed under GNU LGPL and the
MIT X11 licenses. It's compiled against ffmpeg to support more codecs.

But it's wrong what you said, Pierre. If you go to the showcase website
of Microsoft for Silverlight, nearly all demos are working with
moonlight. 

Otherwise to avoid some legal issues (which I don't believe that
there are one) we can say to our users that they can install it through
this website: http://go-mono.com/moonlight/download.aspx 

Otherwise if someone want to develop silverlight/moonlight application
under Arch Linux he can't because of the missing SDK which comes with
the package I would build from source.

About the Covenant... thing, I don't really understand it, it's too
much high english for me.
 
 Daniel

Re: [arch-dev-public] Moonlight in Arch Linux

[Daniel Isenmann]

On Tue, 22 Dec 2009 11:40:28 -0600
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Tue, Dec 22, 2009 at 11:28 AM, Pierre Schmitz
 pie...@archlinux.de wrote:
  On Tue, 22 Dec 2009 11:12:30 -0600, Aaron Griffin
  aaronmgrif...@gmail.com
  wrote:
  However, isn't there some legal issues with Moonlight? I saw
  recently that Microsoft pledged not to sue Moonlight users
 
  There are no issues as software patents do not exist for us. :P
 
  http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
 
  Moonlight is licensed under the GPL. Who cares what patent problems
  it might have in the US?
 
  Of course this plugin is quite useless anyway (only works with
  firefox and those few sites using silverlight only seem to support
  the microsoft implementation). But I am fine with it if Daniel
  wants to maintain it.
 
 Well, there are those of us here in the US and we do have US users and
 mirrors. From a reading of the Groklaw piece[1], I see it as
 Microsoft can sue any users of the software that did not get
 Moonlight direct from Novell. The Downstream Recipients part of the
 covenant seems to NOT cover mirrors. This says to me that we'd be
 opening up our mirrors to being sued for redistribution of patented
 material.
 
 As for the Who care's what patent problems it might have in the US?
 part - I care. US users care. US mirrors care. We've already taken
 steps to specifically appease the German audience (remember: we
 removed Analytics because of some German law), why doesn't this door
 swing both ways?
 
 1: http://www.groklaw.net/article.php?story=20080528133529454

To fully clear that, I will contact the Moonlight developers. They
should give us the right answer for legal issues if we allowed to
distribute it without any concerns.

Re: [arch-dev-public] Moonlight in Arch Linux

[Daniel Isenmann]

On Tue, 22 Dec 2009 11:40:28 -0600
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Tue, Dec 22, 2009 at 11:28 AM, Pierre Schmitz
 pie...@archlinux.de wrote:
  On Tue, 22 Dec 2009 11:12:30 -0600, Aaron Griffin
  aaronmgrif...@gmail.com
  wrote:
  However, isn't there some legal issues with Moonlight? I saw
  recently that Microsoft pledged not to sue Moonlight users
 
  There are no issues as software patents do not exist for us. :P
 
  http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
 
  Moonlight is licensed under the GPL. Who cares what patent problems
  it might have in the US?
 
  Of course this plugin is quite useless anyway (only works with
  firefox and those few sites using silverlight only seem to support
  the microsoft implementation). But I am fine with it if Daniel
  wants to maintain it.
 
 Well, there are those of us here in the US and we do have US users and
 mirrors. From a reading of the Groklaw piece[1], I see it as
 Microsoft can sue any users of the software that did not get
 Moonlight direct from Novell. The Downstream Recipients part of the
 covenant seems to NOT cover mirrors. This says to me that we'd be
 opening up our mirrors to being sued for redistribution of patented
 material.
 
 As for the Who care's what patent problems it might have in the US?
 part - I care. US users care. US mirrors care. We've already taken
 steps to specifically appease the German audience (remember: we
 removed Analytics because of some German law), why doesn't this door
 swing both ways?
 
 1: http://www.groklaw.net/article.php?story=20080528133529454

I have talked to the moonlight developers. The posted covenant on the
Microsoft website is the old one. This has been updated some days ago
and it's now safe for everyone to use/distribute moonlight without any
fear to be sued by Microsoft. 

Miguel has blogged about it some days ago:
http://tirania.org/blog/archive/2009/Dec-17.html

Microsoft has an updated patent covenant that will covers third party
distributions.

Another linked article from Miguel is here which clears the situation
even more: http://www.linuxplanet.com/linuxplanet/reports/6932/1/
(Novell Moonlight 2.0 Gets Microsoft's Blessing / Moonlight for all
Linux Users):

 snip
They can take the source, do any patches they need to do to make sure
it integrates with their system, and redistribute the binaries, De
Icaza told InternetNews.com. Anyone can take Moonlight and run it on
any platform that they want and they can even modify it without Novell
involvement and without the fear that Microsoft might not like that.

While Moonlight itself is open source and now covered by the extended
Microsoft patent covenant, the media codecs necessary for audio and
video will continue to be treated differently. Moonlight includes the
Microsoft Media Pack, which is a set of proprietary codecs that
Microsoft has licensed from their own patent holders and makes
available to Moonlight users, free of charge.
---snip

So we should be safe to distribute it and do what we want with the
package.

@Aaron: You were right with the old covenant, but with the new one we
have nothing to worry about. I will wait with the packaging after they
updated the website with the new one.

 Daniel

Re: [arch-dev-public] [signoff] kernel 2.6.32.1-1

[Daniel Isenmann]

On Tue, 15 Dec 2009 20:31:03 +0100
Tobias Powalowski t.p...@gmx.de wrote:

 Hi guys,
 
 Upstream changes:
 http://kernelnewbies.org/LinuxChanges
 
 Arch Linux bugfixes/feature requests:
 http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG 
 http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE
 
 Arch Linux changes:
 - splitted kernel-headers to extra package
   If you want to build external modules please install:
   pacman -S kernel26-headers
   Please change your PKGBUILDS to makedepend on this package.
 - added xen support to 64bit kernel
 - changed intel kms enabled by default
 - changed to new firewire subsystem:
 http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
 
 Please signoff both arches,
 
 greetings
 tpowa

Signoff x86_64. Everything runs.

Daniel

Re: [arch-dev-public] Cronjob for regular git garbage collection

[Daniel Isenmann]

 When I broke our projects.archlinux.org vhost, I noticed that cloning 
 git via http:// takes ages. This could be vastly improved by running a 
 regular cronjob to 'git gc' all /srv/projects/git repositories. It would 
 also speed up cloning/pulling via git://, as the remote: compressing 
 objects stage will be much less work on the server. Are there any 
 objections against setting this up?

I'm not so familiar with git internals on the git server, but it sounds 
reasonable to me what you said. Even the documentation of git gc says: 

Users are encouraged to run this task on a regular basis within each 
repository to maintain good disk space utilization and good operating 
performance.

So, I say +1 from my (not-so-familiar-git) side.

Daniel  
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

[arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

Hi,

I'm having some trouble to understand why pacman left some files on the
filesystem, but the package was removed. According to this bug report:
http://bugs.archlinux.org/task/16414 pacman left the listed directories
and files on the filesystem. I have try to reproduce it and it's true,
the files are on the filesystem. My first thought was about the
'emptydirs' option in the PKGBUILD
(http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD),
but that wasn't the solution, the files are still there.

I can't determine why this happens, any ideas from your side?

 -Daniel

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 12:38:40 -0500
Dan McGee dpmc...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 11:45 AM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  Hi,
 
  I'm having some trouble to understand why pacman left some files on
  the filesystem, but the package was removed. According to this bug
  report: http://bugs.archlinux.org/task/16414 pacman left the listed
  directories and files on the filesystem. I have try to reproduce it
  and it's true, the files are on the filesystem. My first thought
  was about the 'emptydirs' option in the PKGBUILD
  (http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD),
  but that wasn't the solution, the files are still there.
 
  I can't determine why this happens, any ideas from your side?
 
 Files or directories? They are handled quite differently.
 
 After you install, can you post the contents of the files file from
 /var/lib/pacman/local/wicd*/files ?

Here is the content and at the bottom the left files/directories after
removing:

--

$ cat /var/lib/pacman/local/wicd-1.6.2.2-2/files 
%FILES%
etc/
etc/dbus-1/
etc/dbus-1/system.d/
etc/dbus-1/system.d/wicd.conf
etc/rc.d/
etc/rc.d/wicd
etc/wicd/
etc/wicd/encryption/
etc/wicd/encryption/templates/
etc/wicd/encryption/templates/active
etc/wicd/encryption/templates/eap
etc/wicd/encryption/templates/eap-tls
etc/wicd/encryption/templates/leap
etc/wicd/encryption/templates/peap
etc/wicd/encryption/templates/peap-tkip
etc/wicd/encryption/templates/ttls
etc/wicd/encryption/templates/wep-hex
etc/wicd/encryption/templates/wep-passphrase
etc/wicd/encryption/templates/wep-shared
etc/wicd/encryption/templates/wpa
etc/wicd/encryption/templates/wpa-psk
etc/wicd/scripts/
etc/wicd/scripts/postconnect/
etc/wicd/scripts/postdisconnect/
etc/wicd/scripts/preconnect/
etc/wicd/scripts/predisconnect/
etc/xdg/
etc/xdg/autostart/
etc/xdg/autostart/wicd-tray.desktop
usr/
usr/bin/
usr/bin/wicd-client
usr/bin/wicd-curses
usr/lib/
usr/lib/pm-utils/
usr/lib/pm-utils/sleep.d/
usr/lib/pm-utils/sleep.d/55wicd
usr/lib/python2.6/
usr/lib/python2.6/site-packages/
usr/lib/python2.6/site-packages/Wicd-1.6.2.2-py2.6.egg-info
usr/lib/python2.6/site-packages/wicd/
usr/lib/python2.6/site-packages/wicd/__init__.py
usr/lib/python2.6/site-packages/wicd/__init__.pyc
usr/lib/python2.6/site-packages/wicd/backend.py
usr/lib/python2.6/site-packages/wicd/backend.pyc
usr/lib/python2.6/site-packages/wicd/configmanager.py
usr/lib/python2.6/site-packages/wicd/configmanager.pyc
usr/lib/python2.6/site-packages/wicd/dbusmanager.py
usr/lib/python2.6/site-packages/wicd/dbusmanager.pyc
usr/lib/python2.6/site-packages/wicd/gui.py
usr/lib/python2.6/site-packages/wicd/gui.pyc
usr/lib/python2.6/site-packages/wicd/guiutil.py
usr/lib/python2.6/site-packages/wicd/guiutil.pyc
usr/lib/python2.6/site-packages/wicd/logfile.py
usr/lib/python2.6/site-packages/wicd/logfile.pyc
usr/lib/python2.6/site-packages/wicd/misc.py
usr/lib/python2.6/site-packages/wicd/misc.pyc
usr/lib/python2.6/site-packages/wicd/netentry.py
usr/lib/python2.6/site-packages/wicd/netentry.pyc
usr/lib/python2.6/site-packages/wicd/networking.py
usr/lib/python2.6/site-packages/wicd/networking.pyc
usr/lib/python2.6/site-packages/wicd/prefs.py
usr/lib/python2.6/site-packages/wicd/prefs.pyc
usr/lib/python2.6/site-packages/wicd/translations.py
usr/lib/python2.6/site-packages/wicd/translations.pyc
usr/lib/python2.6/site-packages/wicd/wnettools.py
usr/lib/python2.6/site-packages/wicd/wnettools.pyc
usr/lib/python2.6/site-packages/wicd/wpath.py
usr/lib/python2.6/site-packages/wicd/wpath.pyc
usr/lib/wicd/
usr/lib/wicd/__init__.py
usr/lib/wicd/autoconnect.py
usr/lib/wicd/backend.py
usr/lib/wicd/backends/
usr/lib/wicd/backends/be-external.py
usr/lib/wicd/backends/be-ioctl.py
usr/lib/wicd/configmanager.py
usr/lib/wicd/configscript.py
usr/lib/wicd/configscript_curses.py
usr/lib/wicd/curses_misc.py
usr/lib/wicd/dbusmanager.py
usr/lib/wicd/gui.py
usr/lib/wicd/guiutil.py
usr/lib/wicd/logfile.py
usr/lib/wicd/misc.py
usr/lib/wicd/monitor.py
usr/lib/wicd/netentry.py
usr/lib/wicd/netentry_curses.py
usr/lib/wicd/networking.py
usr/lib/wicd/prefs.py
usr/lib/wicd/prefs_curses.py
usr/lib/wicd/suspend.py
usr/lib/wicd/translations.py
usr/lib/wicd/wicd-client.py
usr/lib/wicd/wicd-curses.py
usr/lib/wicd/wicd-daemon.py
usr/lib/wicd/wnettools.py
usr/lib/wicd/wpath.py
usr/sbin/
usr/sbin/wicd
usr/share/
usr/share/applications/
usr/share/applications/wicd.desktop
usr/share/doc/
usr/share/doc/wicd/
usr/share/doc/wicd/AUTHORS
usr/share/doc/wicd/CHANGES
usr/share/doc/wicd/INSTALL
usr/share/doc/wicd/LICENSE
usr/share/doc/wicd/README
usr/share/icons/
usr/share/icons/hicolor/
usr/share/icons/hicolor/128x128/
usr/share/icons/hicolor/128x128/apps/
usr/share/icons/hicolor/128x128/apps/wicd-client.png
usr/share/icons/hicolor/16x16/
usr/share/icons/hicolor/16x16/apps/
usr/share/icons/hicolor/16x16/apps/wicd-client.png
usr/share/icons/hicolor/192x192/
usr/share/icons/hicolor/192x192/apps/
usr/share/icons/hicolor/192x192

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 14:45:20 -0400
Eric Bélanger snowmanisc...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard twilla...@gmail.com
 wrote:
  As I can see now, these are .pyo files. Are they generate at
  runtime or something like that? They are not in the package.
 
 
  .pyo files are, I believe, optimized python files generated
  during runtime.
 
 
 I beleiie so too.  I think there was a thread about how to deal with
 these files.  I think the info is in a wiki article about python
 packaging guidelines. The other remaining file is wicd.log wich is
 generated at runtime too.

I have nothing found about those files. The article about python
package guidelines is very short. Nothing special about it.

The log file is acceptable, but the pyo files are annyoing.

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 14:08:33 -0500
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  On Mon, 19 Oct 2009 14:45:20 -0400
  Eric Bélanger snowmanisc...@gmail.com wrote:
 
  On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard
  twilla...@gmail.com wrote:
   As I can see now, these are .pyo files. Are they generate at
   runtime or something like that? They are not in the package.
  
  
   .pyo files are, I believe, optimized python files generated
   during runtime.
  
 
  I beleiie so too.  I think there was a thread about how to deal
  with these files.  I think the info is in a wiki article about
  python packaging guidelines. The other remaining file is wicd.log
  wich is generated at runtime too.
 
  I have nothing found about those files. The article about python
  package guidelines is very short. Nothing special about it.
 
  The log file is acceptable, but the pyo files are annyoing.
 
 I imagine that this only happens with apps run as root (or have write
 permissions to their install dir).
 
 I think the best thing, for the time being, is to do this in a
 pre_remove (so you have access to pacman -Ql at that time) and do
 something like:
 
 PKGNAME=wicd
 pre_remove () {
 for pyo in $(pacman -Qql $PKGNAME  | grep \.py$ | sed
 's|.py$|.pyo|g'); do if [ -f $pyo ]; then
 rm $pyo
 fi
 done
 }

Ok, I will do it this way, but shouldn't we have a better solution for
this for the future?

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 14:56:02 -0500
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger
 snowmanisc...@gmail.com wrote:
  On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin
  aaronmgrif...@gmail.com wrote:
  On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann
  daniel.isenm...@gmx.de wrote:
  On Mon, 19 Oct 2009 14:08:33 -0500
  Aaron Griffin aaronmgrif...@gmail.com wrote:
 
  On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann
  daniel.isenm...@gmx.de wrote:
   On Mon, 19 Oct 2009 14:45:20 -0400
   Eric Bélanger snowmanisc...@gmail.com wrote:
  
   On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard
   twilla...@gmail.com wrote:
As I can see now, these are .pyo files. Are they generate
at runtime or something like that? They are not in the
package.
   
   
.pyo files are, I believe, optimized python files
generated during runtime.
   
  
   I beleiie so too.  I think there was a thread about how to
   deal with these files.  I think the info is in a wiki article
   about python packaging guidelines. The other remaining file
   is wicd.log wich is generated at runtime too.
  
   I have nothing found about those files. The article about
   python package guidelines is very short. Nothing special about
   it.
  
   The log file is acceptable, but the pyo files are annyoing.
 
  I imagine that this only happens with apps run as root (or have
  write permissions to their install dir).
 
  I think the best thing, for the time being, is to do this in a
  pre_remove (so you have access to pacman -Ql at that time) and do
  something like:
 
  PKGNAME=wicd
  pre_remove () {
      for pyo in $(pacman -Qql $PKGNAME  | grep \.py$ | sed
  's|.py$|.pyo|g'); do if [ -f $pyo ]; then
              rm $pyo
          fi
      done
  }
 
  Ok, I will do it this way, but shouldn't we have a better
  solution for this for the future?
 
  Well, the only sane way to do it would be to make sure pacman
  tracks the .pyo files by generating them as part of the package
  creation process, but I don't even know if that's possible
 
 
  it's possible. Just create empty files with the same name with
  'touch' in the build function.

But then you have to track the files every rebuild, if they really
exists or not.
 
 Looks like python -O py_compile.py foo.py will do this. And it looks
 like setuptools has an --optimize argument. I'd suggest trying this
 
 python setup.py install --optimize=1 ...other args...

This is the correct parameter:

--optimize (-O) 
also compile with optimization: -O1 for python -O, -O2 for python
-OO, and -O0 to disable [default: -O0]

But as the parameter mentioned, it is disabled by
default. :(

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 16:02:15 -0400
Eric Bélanger snowmanisc...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin
 aaronmgrif...@gmail.com wrote:
  On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger
  snowmanisc...@gmail.com wrote:
  On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin
  aaronmgrif...@gmail.com wrote:
  On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann
  daniel.isenm...@gmx.de wrote:
  On Mon, 19 Oct 2009 14:08:33 -0500
  Aaron Griffin aaronmgrif...@gmail.com wrote:
 
  On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann
  daniel.isenm...@gmx.de wrote:
   On Mon, 19 Oct 2009 14:45:20 -0400
   Eric Bélanger snowmanisc...@gmail.com wrote:
  
   On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard
   twilla...@gmail.com wrote:
As I can see now, these are .pyo files. Are they generate
at runtime or something like that? They are not in the
package.
   
   
.pyo files are, I believe, optimized python files
generated during runtime.
   
  
   I beleiie so too.  I think there was a thread about how to
   deal with these files.  I think the info is in a wiki
   article about python packaging guidelines. The other
   remaining file is wicd.log wich is generated at runtime too.
  
   I have nothing found about those files. The article about
   python package guidelines is very short. Nothing special
   about it.
  
   The log file is acceptable, but the pyo files are annyoing.
 
  I imagine that this only happens with apps run as root (or have
  write permissions to their install dir).
 
  I think the best thing, for the time being, is to do this in a
  pre_remove (so you have access to pacman -Ql at that time) and
  do something like:
 
  PKGNAME=wicd
  pre_remove () {
      for pyo in $(pacman -Qql $PKGNAME  | grep \.py$ | sed
  's|.py$|.pyo|g'); do if [ -f $pyo ]; then
              rm $pyo
          fi
      done
  }
 
  Ok, I will do it this way, but shouldn't we have a better
  solution for this for the future?
 
  Well, the only sane way to do it would be to make sure pacman
  tracks the .pyo files by generating them as part of the package
  creation process, but I don't even know if that's possible
 
 
  it's possible. Just create empty files with the same name with
  'touch' in the build function.
 
  Looks like python -O py_compile.py foo.py will do this. And it looks
  like setuptools has an --optimize argument. I'd suggest trying this
 
  python setup.py install --optimize=1 ...other args...
 
 
 yeah, just found that here:
 http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy

Why wasn't that added to the official Python Packaging Policy here:
http://wiki.archlinux.org/index.php/Python_Package_Guidelines

I will change that in the next package version of wicd. I just
committed the other fix, don't want to release the next package
right now. Have to remember that page.

 ML thread I refered to earlier:
 http://mailman.archlinux.org/pipermail/arch-dev-public/2008-December/009525.html

Long time ago ;)

Re: [arch-dev-public] Strange behaviour of pacman

[Daniel Isenmann]

On Mon, 19 Oct 2009 15:10:24 -0500
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Mon, Oct 19, 2009 at 3:08 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  On Mon, 19 Oct 2009 16:02:15 -0400
  Eric Bélanger snowmanisc...@gmail.com wrote:
 
  On Mon, Oct 19, 2009 at 3:56 PM, Aaron Griffin
  aaronmgrif...@gmail.com wrote:
   On Mon, Oct 19, 2009 at 2:49 PM, Eric Bélanger
   snowmanisc...@gmail.com wrote:
   On Mon, Oct 19, 2009 at 3:38 PM, Aaron Griffin
   aaronmgrif...@gmail.com wrote:
   On Mon, Oct 19, 2009 at 2:21 PM, Daniel Isenmann
   daniel.isenm...@gmx.de wrote:
   On Mon, 19 Oct 2009 14:08:33 -0500
   Aaron Griffin aaronmgrif...@gmail.com wrote:
  
   On Mon, Oct 19, 2009 at 2:03 PM, Daniel Isenmann
   daniel.isenm...@gmx.de wrote:
On Mon, 19 Oct 2009 14:45:20 -0400
Eric Bélanger snowmanisc...@gmail.com wrote:
   
On Mon, Oct 19, 2009 at 2:06 PM, Travis Willard
twilla...@gmail.com wrote:
 As I can see now, these are .pyo files. Are they
 generate at runtime or something like that? They are
 not in the package.


 .pyo files are, I believe, optimized python files
 generated during runtime.

   
I beleiie so too.  I think there was a thread about how to
deal with these files.  I think the info is in a wiki
article about python packaging guidelines. The other
remaining file is wicd.log wich is generated at runtime
too.
   
I have nothing found about those files. The article about
python package guidelines is very short. Nothing special
about it.
   
The log file is acceptable, but the pyo files are annyoing.
  
   I imagine that this only happens with apps run as root (or
   have write permissions to their install dir).
  
   I think the best thing, for the time being, is to do this in
   a pre_remove (so you have access to pacman -Ql at that time)
   and do something like:
  
   PKGNAME=wicd
   pre_remove () {
       for pyo in $(pacman -Qql $PKGNAME  | grep \.py$ | sed
   's|.py$|.pyo|g'); do if [ -f $pyo ]; then
               rm $pyo
           fi
       done
   }
  
   Ok, I will do it this way, but shouldn't we have a better
   solution for this for the future?
  
   Well, the only sane way to do it would be to make sure pacman
   tracks the .pyo files by generating them as part of the package
   creation process, but I don't even know if that's possible
  
  
   it's possible. Just create empty files with the same name with
   'touch' in the build function.
  
   Looks like python -O py_compile.py foo.py will do this. And it
   looks like setuptools has an --optimize argument. I'd suggest
   trying this
  
   python setup.py install --optimize=1 ...other args...
  
 
  yeah, just found that here:
  http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
 
  Why wasn't that added to the official Python Packaging Policy
  here: http://wiki.archlinux.org/index.php/Python_Package_Guidelines
 
  I will change that in the next package version of wicd. I just
  committed the other fix, don't want to release the next package
  right now. Have to remember that page.
 
 Added it :)

The only problem is, that architecture 'any' doesn't work anymore with
this install option. But I think that this problem doesn't affect so
much packages to worry about, I think.

[arch-dev-public] Code swarm of Arch Linux SVN repository

[Daniel Isenmann]

Hi,

I have created a code swarm
(http://vis.cs.ucdavis.edu/~ogawa/codeswarm/) of our PKGBUILD SVN. You
can watch it here: http://vimeo.com/7113066

Sadly I haven't any logs from our old CVS, so the video starts with the
big commit from Aaron at April 6th, 2008.

Have fun...

Cheers, 
 Daniel

[arch-dev-public] Moving a package from [community] to [extra]

[Daniel Isenmann]

Hi,

at the moment I'm sitting and try to finalize my Completing mono
support-Task. I would like to move monodevelop (which is orphaned)
and some of its bindings to [extra]. Is it possible to move a package
from [community] to [extra], or have I do it manually?

Cheers,
 Daniel

Re: [arch-dev-public] Moving a package from [community] to [extra]

[Daniel Isenmann]

On Fri, 16 Oct 2009 16:21:11 -0500
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Fri, Oct 16, 2009 at 4:14 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  Hi,
 
  at the moment I'm sitting and try to finalize my Completing mono
  support-Task. I would like to move monodevelop (which is
  orphaned) and some of its bindings to [extra]. Is it possible to
  move a package from [community] to [extra], or have I do it
  manually?
 
 Right now nothing is in place to do that. You will need to do it
 manually. Additionally, I know of no way to move a file from one svn
 repo to another and retain history.

Alright, then I will do it manually. Have I the rights to delete a
package in community? Never tested before.

Re: [arch-dev-public] Moving a package from [community] to [extra]

[Daniel Isenmann]

On Fri, 16 Oct 2009 16:54:10 -0500
Aaron Griffin aaronmgrif...@gmail.com wrote:

 On Fri, Oct 16, 2009 at 4:47 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  On Fri, 16 Oct 2009 16:21:11 -0500
  Aaron Griffin aaronmgrif...@gmail.com wrote:
 
  On Fri, Oct 16, 2009 at 4:14 PM, Daniel Isenmann
  daniel.isenm...@gmx.de wrote:
   Hi,
  
   at the moment I'm sitting and try to finalize my Completing mono
   support-Task. I would like to move monodevelop (which is
   orphaned) and some of its bindings to [extra]. Is it possible to
   move a package from [community] to [extra], or have I do it
   manually?
 
  Right now nothing is in place to do that. You will need to do it
  manually. Additionally, I know of no way to move a file from one
  svn repo to another and retain history.
 
  Alright, then I will do it manually. Have I the rights to delete a
  package in community? Never tested before.
 
 Yeah you should be able to just copy trunk (delete the .svn dir) to
 the main svn repo, svn add it, and svn rm it from community.

Ok, I will try it. Thanks.

Re: [arch-dev-public] Moving a package from [community] to [extra]

[Daniel Isenmann]

On Sat, 17 Oct 2009 00:03:07 +0200
Thomas Bächler tho...@archlinux.org wrote:

 Daniel Isenmann schrieb:
  Alright, then I will do it manually. Have I the rights to delete a
  package in community? Never tested before.
 
 You'll need an account on sigurd and must have the right groups,
 obviously.
 

Thomas is right here, I can't delete it. Can someone please delete
monodevelop from community? Thanks.

Re: [arch-dev-public] Completing support for Mono

[Daniel Isenmann]

On Sat, 10 Oct 2009 15:08:34 +0200
Daniel Isenmann daniel.isenm...@gmx.de wrote:

 On Fri, 09 Oct 2009 00:43:42 +0200
 Thomas Bächler tho...@archlinux.org wrote:
 
  Daniel Isenmann schrieb:
   Hi,
   
   at the moment the mono packages are spread across our repos
   (extra, community and some AUR packages). I would like to complete
   and concentrate our support and adding some new packages to
   [extra]. As you can see (here:
   http://ftp.novell.com/pub/mono/sources-stable/ ) these are the
   complete official mono sources. I would like to add all (only the
   missing) packages of the following groups to [extra]:
   
- Mono (only gluezilla is missing)
- XSP/mod_mono (already in [extra])
- Development Tools (mostly already added)
- MonoDevelop (some packages are in community (orphaned) or AUR)
- Other (in AUR)
   
   I will maintain all of the packages and keep them up-to-date. 
   
   Any objections or opinions?
   
-Daniel
   
  
  We don't ship half a KDE or half a GNOME, so we shouldn't do it
  with mono either. That said, I don't use mono and don't
  particularly care about it.
  
 
 As it seems that there are no objections for this, I will doing
 it soon. Additionally I will add some groups for it to make it
 clearer.
 
  Daniel

I think I have finished the task. Hopefully I haven't forget a package,
I will add it tomorrow if so (It's late and I should go to bed). But
everything is running here on my computer, so it should be complete. 

Re: [arch-dev-public] [signoff] kernel26 2.6.31.3-1

[Daniel Isenmann]

On Fri, 09 Oct 2009 10:48:14 +0200
Thomas Bächler tho...@archlinux.org wrote:

 Thomas Bächler schrieb:
  Thomas Bächler schrieb:
  Another upstream release, I want to move directly after signoff.
 
  Last minute changes:
 
  - Changed number of maximum serial ports to 32
  - Enabled ATI KMS (if this causes problems, blame Andy, he says
  it's fine :D)
 
  Working fine on x86_64, i686 will be ready soon.
 
  
  Minor upstream update, the same holds again. Please sign off.
 
 Anyone? I'd like to move this quickly.
 

Signoff x86_64.

-Daniel