Re: [arch-general] makepkg not working in chrooted environment
Allan McRae [2010.10.22 1028 +1000]: > makepkg uses pacman with the -T flag to test whether a package > installed. That is supposed to be dead quiet. Of course if you > used the --debug flag you would see the message you are after... Fair enough. In particular, I can see why printing an error message may cause a mess, for example, in how makepkg uses pacman -T to list unmet dependencies. Nevertheless, if I'm a user (not a developer) who wonders why pacman isn't doing the right thing, the copious output produced by --debug isn't that helpful, especially because I have to infer from "warning: pkgcache is NULL for db 'local'" that pacman in fact cannot read the contents of /var/lib/pacman/local. So, I still think that an informative error message such as "warning: cannot access /var/lib/pacman/local" would be immensely helpful from a user's perspective. As I said, I see why having such an error message produced by pacman -T is a bad idea, but pacman -Qs, instead of outputting nothing, should produce a warning. Cheers, Norbert
Re: [arch-general] makepkg not working in chrooted environment
On 22/10/10 10:12, Norbert Zeh wrote: Norbert Zeh [2010.10.21 1946 -0300]: Norbert Zeh [2010.10.21 1857 -0300]: Ionuț Bîru [2010.10.22 0017 +0300]: On 10/22/2010 12:07 AM, Norbert Zeh wrote: Hi folks, I am running a 32-bit chroot on my 64-bit system, and I'm trying to build a few packages from AUR inside the 32-bit chroot. When I run makepkg inside the chroot, it complains about dependencies not being satisfied, even though the dependencies are installed inside the chroot (and in the 64-bit environment, as well). So I'm wondering why it doesn't find the dependencies. I'd love to get this to work and also wouldn't mind helping with debugging this. I just need a few pointers what I would have to look for. Cheers, Norbert linux32 chroot /path/to/bla This I did do, and it fails in the chroot, but I'll certainly follow the pointers below and the one Andrea gave. Thanks for the response. Before trying to go down the path of using a separate chroot just for building packages from AUR (as suggested by the wiki references you and Andrea gave), I dug a little deeper into where my problem came from. It turns out that pacman would find the installed packages if run inside the chroot as root but not if run as an unprivileged users (such as the one I normally use to build packages). The culprit was too restrictive restrictions on /var/lib/pacman and the files therein. Changed the permissions, and all worked beautifully by just running makepkg inside the chroot. As a follow-up to this one, I'm wondering whether this is worth a bug report on pacman. After all, if pacman cannot access its DBPath, shouldn't it issue an informative error message rather than silently claiming that a package that's in fact installed is not? makepkg uses pacman with the -T flag to test whether a package installed. That is supposed to be dead quiet. Of course if you used the --debug flag you would see the message you are after... Allan
Re: [arch-general] makepkg not working in chrooted environment
Norbert Zeh [2010.10.21 1946 -0300]: > Norbert Zeh [2010.10.21 1857 -0300]: > > Ionuț Bîru [2010.10.22 0017 +0300]: > > > On 10/22/2010 12:07 AM, Norbert Zeh wrote: > > > >Hi folks, > > > > > > > >I am running a 32-bit chroot on my 64-bit system, and I'm trying to > > > >build a few packages from AUR inside the 32-bit chroot. When I run > > > >makepkg inside the chroot, it complains about dependencies not being > > > >satisfied, even though the dependencies are installed inside the chroot > > > >(and in the 64-bit environment, as well). So I'm wondering why it > > > >doesn't find the dependencies. I'd love to get this to work and also > > > >wouldn't mind helping with debugging this. I just need a few pointers > > > >what I would have to look for. > > > > > > > >Cheers, > > > >Norbert > > > > > > > > > > linux32 chroot /path/to/bla > > > > This I did do, and it fails in the chroot, but I'll certainly follow the > > pointers below and the one Andrea gave. Thanks for the response. > > Before trying to go down the path of using a separate chroot just for > building packages from AUR (as suggested by the wiki references you and > Andrea gave), I dug a little deeper into where my problem came from. It > turns out that pacman would find the installed packages if run inside > the chroot as root but not if run as an unprivileged users (such as the > one I normally use to build packages). The culprit was too restrictive > restrictions on /var/lib/pacman and the files therein. Changed the > permissions, and all worked beautifully by just running makepkg inside > the chroot. As a follow-up to this one, I'm wondering whether this is worth a bug report on pacman. After all, if pacman cannot access its DBPath, shouldn't it issue an informative error message rather than silently claiming that a package that's in fact installed is not? N.
Re: [arch-general] Question about installing libraries
On Fri, Oct 22, 2010 at 01:26:37AM +0200, Christian wrote: > Many thanks, will have a look. > But lets say I can't find a particular library and I only have a .deb file > with it, what to do then? You can write a PKGBUILD that automates the process of unpacking the ".deb" package and installing the libraries into "/usr/lib/". If you build and install a package (e.g. using `makepkg -i`) instead of copying them manually, all libraries will be tracked by pacman(8). If you never created a PKGBUILD before, you might wanna read something about it in the wiki ([1], [2]). If you want an example how to do create a package suitable for installation with pacman(8) from a dpkg, you can check [1] (even tho this PKGBUILD isn't the best I've ever seen). [1] http://wiki.archlinux.org/index.php/Creating_Packages [2] http://wiki.archlinux.org/index.php/Arch_Packaging_Standards [3] https://aur.archlinux.org/packages.php?ID=12819
Re: [arch-general] Question about installing libraries
Hi, On 2010-10-22 at 09:32 Allan McRae wrote: >On 22/10/10 08:42, Christian wrote: >> For example, I now need to use pygame1.8 and there is 1.9 in the arch >> repository. > >As an aside, most things that work with pygame-1.8 also work with 1.9... > >Allan How is it with python2.5 then?
Re: [arch-general] Question about installing libraries
On 22/10/10 08:42, Christian wrote: For example, I now need to use pygame1.8 and there is 1.9 in the arch repository. As an aside, most things that work with pygame-1.8 also work with 1.9... Allan
Re: [arch-general] Question about installing libraries
Hi,
On 2010-10-22 at 02:20 Evangelos Foutras wrote:
>On Fri, Oct 22, 2010 at 2:10 AM, Christian wrote:
>> OK, but let's say I need some other older library how to search the svn
>> for that?
>
>Find the package you're interested in from
>http://www.archlinux.org/packages/ and click on it. At the right side
>of the package page, you'll see a link named "SVN Entries (trunk)";
>follow it. Now that you're at the websvn interface, click the link
>that reads "View Log".
>
>You are presented with a table that lists the revisions of a specific
>package. On the "Log message" column you'll be able to locate the
>package version you want, and you can then match that to the first
>column ("Rev") which is the revision number you'll checkout.
Many thanks, will have a look.
But lets say I can't find a particular library and I only have a .deb file with
it, what to do then?
Christian
Re: [arch-general] Question about installing libraries
On Fri, Oct 22, 2010 at 2:10 AM, Christian wrote:
> OK, but let's say I need some other older library how to search the svn
> for that?
Find the package you're interested in from
http://www.archlinux.org/packages/ and click on it. At the right side
of the package page, you'll see a link named "SVN Entries (trunk)";
follow it. Now that you're at the websvn interface, click the link
that reads "View Log".
You are presented with a table that lists the revisions of a specific
package. On the "Log message" column you'll be able to locate the
package version you want, and you can then match that to the first
column ("Rev") which is the revision number you'll checkout.
Re: [arch-general] Question about installing libraries
Hello, On 2010-10-22 01:02, Evangelos Foutras wrote: On Fri, Oct 22, 2010 at 1:42 AM, Christian wrote: So my question is if I get a such package, may I just extract it, unpack the data.tar.gz and copy the libraries into /usr/lib? For example, I now need to use pygame1.8 and there is 1.9 in the arch repository. What do you think? You really want to avoid having random untracked files lying around in your system; you want to create packages with them so they are tracked by pacman. A good solution for your problem might be the following: Grab an older revision of the PKGBUILD, change pkgname to something like python-pygame-1.8 and build it. To find the revision you need to fetch, consult the svn log [1]. In this case, for example, you'd want r43882. To checkout that revision use: svn co -r43882 svn://archlinux.org/packages/python-pygame/trunk python-pygame-1.8 [1] http://repos.archlinux.org/wsvn/packages/python-pygame/trunk/?op=log&isdir=1&; OK, but let's say I need some other older library how to search the svn for that? Since I didn't know that it was the r4388 release.
Re: [arch-general] Question about installing libraries
On Fri, Oct 22, 2010 at 1:42 AM, Christian wrote: > So my question is if I get a such package, may I just extract it, unpack the > data.tar.gz and copy the libraries into /usr/lib? > For example, I now need to use pygame1.8 and there is 1.9 in the arch > repository. > What do you think? You really want to avoid having random untracked files lying around in your system; you want to create packages with them so they are tracked by pacman. A good solution for your problem might be the following: Grab an older revision of the PKGBUILD, change pkgname to something like python-pygame-1.8 and build it. To find the revision you need to fetch, consult the svn log [1]. In this case, for example, you'd want r43882. To checkout that revision use: svn co -r43882 svn://archlinux.org/packages/python-pygame/trunk python-pygame-1.8 [1] http://repos.archlinux.org/wsvn/packages/python-pygame/trunk/?op=log&isdir=1&;
Re: [arch-general] makepkg not working in chrooted environment
Norbert Zeh [2010.10.21 1857 -0300]: > Ionuț Bîru [2010.10.22 0017 +0300]: > > On 10/22/2010 12:07 AM, Norbert Zeh wrote: > > >Hi folks, > > > > > >I am running a 32-bit chroot on my 64-bit system, and I'm trying to > > >build a few packages from AUR inside the 32-bit chroot. When I run > > >makepkg inside the chroot, it complains about dependencies not being > > >satisfied, even though the dependencies are installed inside the chroot > > >(and in the 64-bit environment, as well). So I'm wondering why it > > >doesn't find the dependencies. I'd love to get this to work and also > > >wouldn't mind helping with debugging this. I just need a few pointers > > >what I would have to look for. > > > > > >Cheers, > > >Norbert > > > > > > > linux32 chroot /path/to/bla > > This I did do, and it fails in the chroot, but I'll certainly follow the > pointers below and the one Andrea gave. Thanks for the response. Before trying to go down the path of using a separate chroot just for building packages from AUR (as suggested by the wiki references you and Andrea gave), I dug a little deeper into where my problem came from. It turns out that pacman would find the installed packages if run inside the chroot as root but not if run as an unprivileged users (such as the one I normally use to build packages). The culprit was too restrictive restrictions on /var/lib/pacman and the files therein. Changed the permissions, and all worked beautifully by just running makepkg inside the chroot. Cheers, Norbert
[arch-general] Question about installing libraries
Hi all, I am learning and learning more in Arch linux, but I have a question. There are a few programs that I use and I am not able to find all the dependencies in the Arch repositories, and some of th elibraries are a little old and the developers have .deb packages for them. So my question is if I get a such package, may I just extract it, unpack the data.tar.gz and copy the libraries into /usr/lib? For example, I now need to use pygame1.8 and there is 1.9 in the arch repository. What do you think? Many thanks, Christian
Re: [arch-general] makepkg not working in chrooted environment
Ionuț Bîru [2010.10.22 0017 +0300]: > On 10/22/2010 12:07 AM, Norbert Zeh wrote: > >Hi folks, > > > >I am running a 32-bit chroot on my 64-bit system, and I'm trying to > >build a few packages from AUR inside the 32-bit chroot. When I run > >makepkg inside the chroot, it complains about dependencies not being > >satisfied, even though the dependencies are installed inside the chroot > >(and in the 64-bit environment, as well). So I'm wondering why it > >doesn't find the dependencies. I'd love to get this to work and also > >wouldn't mind helping with debugging this. I just need a few pointers > >what I would have to look for. > > > >Cheers, > >Norbert > > > > linux32 chroot /path/to/bla This I did do, and it fails in the chroot, but I'll certainly follow the pointers below and the one Andrea gave. Thanks for the response. N. > > i suggest to read about devtools, it has helpers for that, > extra-i686-build, extra-x86_64-build > > -- > Ionuț -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org- against proprietary attachments
Re: [arch-general] makepkg not working in chrooted environment
On Thursday 21 October 2010 23:07:18 Norbert Zeh wrote: > I am running a 32-bit chroot on my 64-bit system, and I'm trying to > build a few packages from AUR inside the 32-bit chroot. When I run > makepkg inside the chroot, it complains about dependencies not being > satisfied, even though the dependencies are installed inside the chroot > (and in the 64-bit environment, as well). So I'm wondering why it > doesn't find the dependencies. I'd love to get this to work and also > wouldn't mind helping with debugging this. I just need a few pointers > what I would have to look for. IMHO the best way is to use the same scripts that we developers use to build official packages. You should install the 'devtools' package and read something about makechrootpkg on the wiki. -- Andrea Scarpino Arch Linux Developer
Re: [arch-general] makepkg not working in chrooted environment
On 10/22/2010 12:07 AM, Norbert Zeh wrote: Hi folks, I am running a 32-bit chroot on my 64-bit system, and I'm trying to build a few packages from AUR inside the 32-bit chroot. When I run makepkg inside the chroot, it complains about dependencies not being satisfied, even though the dependencies are installed inside the chroot (and in the 64-bit environment, as well). So I'm wondering why it doesn't find the dependencies. I'd love to get this to work and also wouldn't mind helping with debugging this. I just need a few pointers what I would have to look for. Cheers, Norbert linux32 chroot /path/to/bla i suggest to read about devtools, it has helpers for that, extra-i686-build, extra-x86_64-build -- Ionuț
Re: [arch-general] Method to redirect hidden config files in ~
On Thu, Oct 21, 2010 at 10:33 AM, meganox wrote: > On Thu, Oct 14, 2010 at 4:57 PM, C Anthony Risinger wrote: > >> awhile back, i believe it was on this list, there was some messages >> about cleaning up the . in your HOME folder... >> >> can someone point me in the right direction here? i swear all i >> needed to do was export the proper VARS but i cannot seem to find the >> info now. >> >> thanks, >> >> C Anthony >> > > You are thinking of the xdg user directories vars set in the file > ~/.config/user-dirs.dirs: > > http://www.freedesktop.org/wiki/Software/xdg-user-dirs nice, thanks guys. i have yet to actually do this yet, but i'm pretty sure it's the information i was looking for. C Anthony
[arch-general] makepkg not working in chrooted environment
Hi folks, I am running a 32-bit chroot on my 64-bit system, and I'm trying to build a few packages from AUR inside the 32-bit chroot. When I run makepkg inside the chroot, it complains about dependencies not being satisfied, even though the dependencies are installed inside the chroot (and in the 64-bit environment, as well). So I'm wondering why it doesn't find the dependencies. I'd love to get this to work and also wouldn't mind helping with debugging this. I just need a few pointers what I would have to look for. Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org- against proprietary attachments
Re: [arch-general] Spell Checking in Emacs
Frédéric Perrin writes: > Le mercredi 20 à 22:47, Rthoreau a écrit : >> What would be ideal is to get Hunspell working if you follow the >> emacswiki I still do not have a valid Hunspell working on two operating >> systems. One being Arch, the other OpenIndiana so I had to resort back >> to aspell for both. > > Is the problem that you are sharing you .emacs between the two OSs, but > Hunspell is available on only one? In that case, what about: > > (if (string-match "-ARCH" operating-system-release) > (use hunspell) > (fallback to aspell)) > > Or: > > (if (executable-find "hunspell") > (use hunspell...) > (fallback to aspell)) Here is the link I was referring too, I actually have two spell checkers one is Hunspell the other is Aspell. Hunspell works great on the command line but is still borked in emacs. Of course I get a similar problem in Arch, but with function unfound if I copy the examples out of the emacswiki my .emacs file will not even run due to errors, not to mention even if it is tweaked to my configuration. http://opensolaris.org/jive/thread.jspa?threadID=107384 If you try to spell check a word by using "M-x ispell-word", you get the error message "ispell-get-word: Wrong type argument: stringp, nil". "M-x ispell-buffer" produces Spell checking test-buffer using hunspell with en-US dictionary... Spell-checking using hunspell with en-US dictionary done ispell-get-line: Wrong type argument: stringp, nil So if anyone has a valid .emacs hunspell under Arch let me know as of yet I have no idea as to why Hunspell won't work. That is why I use Aspell at the moment. Rthoreau
Re: [arch-general] What's happening about libdjvu?
Am 21.10.2010 17:29, schrieb Dan McGee: > On Thu, Oct 21, 2010 at 10:22 AM, Thomas Bächler wrote: >> Right now, the delay between updating the package info and the file list >> can be (in the worst case) little over 24 hours. Given that our packages >> update and change frequently, I think we should avoid confusion like in >> Auguste's case. > > It's actually updated every 12 hours, and this is an extreme case. We > shouldn't hide the filelist for all new packages when 90% of the time > the list doesn't change. We can put a "this might be out of date" > message there quite easily, I'll look into it sometime but a feature > request/bug report would be awesome so I don't lose track of it. Done. https://bugs.archlinux.org/task/21394 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Method to redirect hidden config files in ~
On Thu, Oct 14, 2010 at 4:57 PM, C Anthony Risinger wrote: > awhile back, i believe it was on this list, there was some messages > about cleaning up the . in your HOME folder... > > can someone point me in the right direction here? i swear all i > needed to do was export the proper VARS but i cannot seem to find the > info now. > > thanks, > > C Anthony > You are thinking of the xdg user directories vars set in the file ~/.config/user-dirs.dirs: http://www.freedesktop.org/wiki/Software/xdg-user-dirs
Re: [arch-general] What's happening about libdjvu?
On Thu, Oct 21, 2010 at 10:22 AM, Thomas Bächler wrote: > Am 21.10.2010 15:56, schrieb Auguste Pop: >> I noticed this by compiling the package myself... When I sent this >> mail, the web page was not updated and I saw an old list of files that >> did not contain the .so file. I should have tried it first rather than >> relying on a presumably delayed response on the web site. Sorry for >> the false alarm. > > The update of the file list in the web interface might be delayed > compared to the update of the package data itself. > > Dan, what can we do here? Should a version mismatch between $repo.db and > $repo.files cause archweb to discard the file list, stating that "There > is currently no file list available for this package", or should archweb > print a warning "This is a file list from an older version of this > package and might differ from the current package". Is anything like > this already done in archweb? Should it? > > Right now, the delay between updating the package info and the file list > can be (in the worst case) little over 24 hours. Given that our packages > update and change frequently, I think we should avoid confusion like in > Auguste's case. It's actually updated every 12 hours, and this is an extreme case. We shouldn't hide the filelist for all new packages when 90% of the time the list doesn't change. We can put a "this might be out of date" message there quite easily, I'll look into it sometime but a feature request/bug report would be awesome so I don't lose track of it. -Dan
Re: [arch-general] What's happening about libdjvu?
Am 21.10.2010 15:56, schrieb Auguste Pop: > I noticed this by compiling the package myself... When I sent this > mail, the web page was not updated and I saw an old list of files that > did not contain the .so file. I should have tried it first rather than > relying on a presumably delayed response on the web site. Sorry for > the false alarm. The update of the file list in the web interface might be delayed compared to the update of the package data itself. Dan, what can we do here? Should a version mismatch between $repo.db and $repo.files cause archweb to discard the file list, stating that "There is currently no file list available for this package", or should archweb print a warning "This is a file list from an older version of this package and might differ from the current package". Is anything like this already done in archweb? Should it? Right now, the delay between updating the package info and the file list can be (in the worst case) little over 24 hours. Given that our packages update and change frequently, I think we should avoid confusion like in Auguste's case. signature.asc Description: OpenPGP digital signature
Re: [arch-general] What's happening about libdjvu?
I noticed this by compiling the package myself... When I sent this mail, the web page was not updated and I saw an old list of files that did not contain the .so file. I should have tried it first rather than relying on a presumably delayed response on the web site. Sorry for the false alarm. > Message: 6 > Date: Thu, 21 Oct 2010 13:43:43 +0200 > From: Thomas B?chler > Subject: Re: [arch-general] What's happening about libdjvu? > To: General Discussion about Arch Linux > Message-ID: <4cc0276f.9050...@archlinux.org> > Content-Type: text/plain; charset="iso-8859-15" > > Am 21.10.2010 13:38, schrieb Auguste Pop: >> For instance, >> /usr/lib/evince/3/backends/libdjvudocument.so from evince package >> links to /usr/lib/libdjvulibre.so.21, which would be removed if I >> update the system to allow djvulibre to replace libdjvu. > > This is false, the djvulibre package contains this library. > > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 262 bytes > Desc: OpenPGP digital signature > URL: > <http://mailman.archlinux.org/pipermail/arch-general/attachments/20101021/575a37a9/attachment-0001.bin> >
Re: [arch-general] Python 3 Rationale?
On Thu, Oct 21, 2010 at 3:45 PM, Armando M. Baratti < ambaratti.lis...@gmail.com> wrote: > > > Yes, off course I do. But I also realize that, besides Python isn't the > easiest platform to deploy to, specially when your customers aren't tech > savvy and have to make some adjustment or install some module, we end with > incompatible platforms for development (Arch Linux, that uses python3 by > default) and deployment (some other distro that uses python2). > This isn't the end of the world, by adds to the things that contribute for > the appearing of problems on the deploying (specially on rather larger > ones). > > > Armando > I'm not sure it's really a good idea to have a development platform different from the production platform unless you deploy on heterogeneous environments. -- Cédric Girard
Re: [arch-general] Spell Checking in Emacs
Le mercredi 20 à 22:47, Rthoreau a écrit : > What would be ideal is to get Hunspell working if you follow the > emacswiki I still do not have a valid Hunspell working on two operating > systems. One being Arch, the other OpenIndiana so I had to resort back > to aspell for both. Is the problem that you are sharing you .emacs between the two OSs, but Hunspell is available on only one? In that case, what about: (if (string-match "-ARCH" operating-system-release) (use hunspell) (fallback to aspell)) Or: (if (executable-find "hunspell") (use hunspell...) (fallback to aspell)) -- Fred
Re: [arch-general] Python 3 Rationale?
Em 20-10-2010 13:21, Daenyth Blank escreveu: On Wed, Oct 20, 2010 at 11:16, Armando M. Baratti wrote: Em 20-10-2010 05:24, Stefano Z. escreveu: anyone know if reportlab does work with python3 ? No, reportlab doesn't work with python3. Neither Django, nor Twisted. As well the modules below are incompatible with python3 (to mention a few): - PyGTK2 - Pyjamas - Kiwi - Beaker - Cheetah - CherryPy - nose - Paste - numpy - PyChecker - pycrypto - egenix utilities (used by many db connectors) - psycopg - couchdbkit - Elixir - MySQL-python - PyMySQL - PyDB2 And many, many more. It'll be a long time for many of these modules be converted (rewritten in some cases) to python3. It was a smart move from the standpoint of package management, but from the point of view of a developer... Armando You do realize that python 2 is not being taken away, right? Yes, off course I do. But I also realize that, besides Python isn't the easiest platform to deploy to, specially when your customers aren't tech savvy and have to make some adjustment or install some module, we end with incompatible platforms for development (Arch Linux, that uses python3 by default) and deployment (some other distro that uses python2). This isn't the end of the world, by adds to the things that contribute for the appearing of problems on the deploying (specially on rather larger ones). Armando
Re: [arch-general] Python 3 Rationale?
Just a little story that is relevant to this discussion I ran into a problem with python and proprietary software earlier today, but was able (through much tribulaton) to work around it. Even after most open- source code is using python 3, a lot of proprietary stuff may still depend on python 2 and it won't be easy to switch it. This is something we may want to consider before we retire python2 altogether. I was setting up a new printer (an HP Laserjet p1120w) which works with hplip, but requires a proprietary plugin from HP's server. The hp-toolbox and hp- plugin utilities that are the interface finstalling the proprietary plugin are both written in python (with a lot of shell script mixed in for good measure). The PKGBUILD for hplip seems to do the right thing in that it uses python2 to execute the hp-toolbox code. But the plugin itself arrives as a self- extracting executable that unpacks a python2 script which it executes using the system python (i.e. python3 on my system). This caused the installer to crash, preventing me from installing the printer driver. Furthermore, after an unsuccessful install, the archive deletes itself and any of the files that were in it. Fortuately, I discovered that if you extract the plugin-archive by hand (you have to wget it first), it provides a compile flag that waits for user input after extraction, but before installation. I was able to access the extracted plugin install script and replace "python" with "python2". I managed to get the printer installed and set up (and print my lecture notes just in time for class) without any further problems. On Tuesday, October 19, 2010 10:00:29 pm Max Countryman wrote: > Apologies, link cut in original quote: > http://mail.python.org/pipermail/python-3000/2008-February/011910.html > > On Oct 19, 2010, at 9:58 PM, Max Countryman wrote: > >> I failed to find a reference, but I seem to remember the Python team > >> deciding at some point that they intended to keep the name "python" > >> for the Python 2.X binaries perpetually, and require Python 3.X to be > >> invoked as "python3". Arch might be alone in making this change, and > >> inconsistent with other Python distributions. EDIT: I can't find a > >> conclusive decision but here is one discussion on the subject: > >> http://mail.python.org/pipermail/python-3000/2008-February/0... > > > > There is any interesting conversation taking place over at Hacker News: > > http://news.ycombinator.com/item?id=1808840 signature.asc Description: This is a digitally signed message part.
Re: [arch-general] What's happening about libdjvu?
On 21/10/10 21:38, Auguste Pop wrote: Hi, The package djvulibre now conflicts and provides libdjvu, and libdjvu disappeared from the repository. However, judging by the files they provide and the PKGBUILD cached in my abs directory, I don't think they are the same thing. djvulibre does not provide the dynamic linked library as libdjvu does and thus may break other application depending on libdjvu. For instance, /usr/lib/evince/3/backends/libdjvudocument.so from evince package links to /usr/lib/libdjvulibre.so.21, which would be removed if I update the system to allow djvulibre to replace libdjvu. What's happened to the libdjvu package? Why is it removed from repository? Should I file a bug report? The new package looks to contain that library to me... [al...@gerolde ~]$ tar -tf /srv/ftp/extra/os/i686/djvulibre-3.5.23-1-i686.pkg.tar.xz | grep usr/lib usr/lib/ usr/lib/pkgconfig/ usr/lib/libdjvulibre.so.21.2.0 usr/lib/libdjvulibre.so usr/lib/libdjvulibre.so.21 usr/lib/pkgconfig/ddjvuapi.pc
Re: [arch-general] What's happening about libdjvu?
On 10/21/2010 02:38 PM, Auguste Pop wrote: Hi, The package djvulibre now conflicts and provides libdjvu, and libdjvu disappeared from the repository. However, judging by the files they provide and the PKGBUILD cached in my abs directory, I don't think they are the same thing. djvulibre does not provide the dynamic linked library as libdjvu does and thus may break other application depending on libdjvu. For instance, /usr/lib/evince/3/backends/libdjvudocument.so from evince package links to /usr/lib/libdjvulibre.so.21, which would be removed if I update the system to allow djvulibre to replace libdjvu. What's happened to the libdjvu package? Why is it removed from repository? Should I file a bug report? Best Regards, that is replacing libdjvu and nothing that you say above is true. pacman -Ql djvulibre | grep libdjvulibre.so djvulibre /usr/lib/libdjvulibre.so djvulibre /usr/lib/libdjvulibre.so.21 djvulibre /usr/lib/libdjvulibre.so.21.2.0 this means that /usr/lib/evince/3/backends/libdjvudocument.so is not broken because djvulibre provides the same soname -- Ionuț
Re: [arch-general] What's happening about libdjvu?
Am 21.10.2010 13:38, schrieb Auguste Pop: > For instance, > /usr/lib/evince/3/backends/libdjvudocument.so from evince package > links to /usr/lib/libdjvulibre.so.21, which would be removed if I > update the system to allow djvulibre to replace libdjvu. This is false, the djvulibre package contains this library. signature.asc Description: OpenPGP digital signature
[arch-general] What's happening about libdjvu?
Hi, The package djvulibre now conflicts and provides libdjvu, and libdjvu disappeared from the repository. However, judging by the files they provide and the PKGBUILD cached in my abs directory, I don't think they are the same thing. djvulibre does not provide the dynamic linked library as libdjvu does and thus may break other application depending on libdjvu. For instance, /usr/lib/evince/3/backends/libdjvudocument.so from evince package links to /usr/lib/libdjvulibre.so.21, which would be removed if I update the system to allow djvulibre to replace libdjvu. What's happened to the libdjvu package? Why is it removed from repository? Should I file a bug report? Best Regards,
