- Arch-general - lists.archlinux.org

Re: [arch-general] Lyx and texlive don't allow viewing the document as pdf, ps, or dvi
by Ravi Desai 15 Jul '08

15 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh, I figured out what the problem was. /opt/texlive/bin was not included in the PATH, so I added it in /etc/profile, logged back in, the my files are showing perfectly. Thank you, Ravi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh8/xQACgkQFPWImGkPaMLkIQCcDkk/ePHegXZJ4ClongXorQ0g ZXQAn34r5549wDBvSKSx757C4SNsKYIB =3OIt -----END PGP SIGNATURE-----

2 1

[arch-general] Lyx and texlive don't allow viewing the document as pdf, ps, or dvi
by Ravi Desai 15 Jul '08

15 Jul '08

Hello, I have installed lyx, and texlive (from community). I am now (I had tetex earlier and it was working fine) unable to view my documents by clicking View -> DVI or View -> PDF or by clicking the PDF, DVI, and PS buttons on the toolbar. I keep getting the error dialog box "File does not exist: /tmp/lyx_tmpdir[random letters and numbers]/lyx_tmpbuf0/foo.dvi" or "blah: blah/foo.pdf" or "blah: /blah/foo.ps". Does anyone know how I may solve this problem? I could go back to tetex, but I'd feel more satisfied with finding a solution to the problem, so here I am :) . Thank you ravster.

5 4

[arch-general] pidgin bug?
by David Rosenstrauch 11 Jul '08

11 Jul '08

Another one: Seems like the upgrade to pidgin 2.4.3 removed some functionality. In an IRC window, the list of users in the room used to appear in multiple colors, IIRC. Now they're all in the standard WM text color (white, in my case). Again, anyone know of a workaround, and/or an Arch or Pidgin bug report on this? Tnx, DR

1 1

[arch-general] firefox 3 tabs bug?
by David Rosenstrauch 11 Jul '08

11 Jul '08

Been having a weird issue with FF3. Thought I'd check here before filing a bug report either with Arch or Mozilla. I have FF configured with "New pages should be opened in: a new tab" (as opposed to a new window). However, as per the FF help, they do the "proper" thing and ignore this setting when a page requests to open a window of a specific size: "Tabs Preferences New pages should be opened in: This preference controls whether links from other applications or from web pages which request to open them in new windows are opened in a new window or a new tab in the most recent window. Note: If you have chosen to open pages in new tabs, Firefox will ignore this preference and will open a new window from a link if the page author specified that the new window should have a specific size, because some pages can only be displayed correctly at a specific size." This all worked perfectly in FF2. Pages were always opened in new tabs, with the exception of pages that wanted to open themselves in "dialog" style external windows of a particular size. However, this behavior is totally borked in FF3. FF3 no longer ignores the setting and opens a new window when a particular window size is requested. Instead, it *always* opens new pages in a new, even if they're intended to be dialogs. And even worse, after opening the page in a new tab, it then proceeds to resize the existing browser window to the size requested. This is obviously really irritating, as my browser window keeps getting resized on my, and I have to keep manually restoring it back to my preferred size. Anyone else seeing this? If so, know of a fix or a workaround? If not, anyone know if there's already a bug report open about this on Arch or Mozilla? Tnx, DR

1 0

[arch-general] How to flag out of date for package in community
by 甘露(Lu Gan) 11 Jul '08

11 Jul '08

I can't find way to flag out of date for package in community, any suggestion? Thanks.

3 2

[arch-general] firefox-i18n Dependency and package mainteiner contact
by raca 10 Jul '08

10 Jul '08

Hi, I don't how to contact the package maintainer of firefox-i18n so I write to here. This in order to correct the dependency from firefox=3.0 to firefox>=3.0 ( and firefox <=4.0 maybe). Other thing, how can generally someone contact the package maintainer? Cheers

6 5

[arch-general] Problems with snort package
by Kessia 'even' Pinheiro 09 Jul '08

09 Jul '08

Hi everyone, I did a snort instalation using the package from extra, but i got some problems. The package does not works after a fresh install. The problems are: - There are some problematic links with /usr/src/lib/snort_* - The conf /etc/snort/snort.conf doesn't load the rules, because the rules arent there! - The start script /etc/rc.d/snort doesn't start because the $SNORT_ARGS is blank. That should be some SNORT_OPTIONS and they are in /etc/conf.d/snort, but are never read. - The /etc/conf.d/snort is never used, and the security or incremental arguments like user, group or interface aren't used. So the user can edit it, but will never have efect. So, after that (and some more problems that i do not remember, I made another package [1], fixed all the problems and made some changes. [1] http://even.archlinux-br.org/things/arch/snort.tar.gz Thats all! -- Kessia Pinheiro Bacharelanda em Ciência da Computação - UFBa Linux Counter User #389695 - [http://counter.li.org] Colaboradora do Projeto Arch Linux Brasil http://even.archlinux-br.org

3 3

[arch-general] latex2rtf missing URL
by Grigorios Bouzakis 09 Jul '08

09 Jul '08

Hi, i was about to file a bug report cause in the web interface latex2rtf is missing the URL string, but then when i browsed SVN i saw that the package included a URL address. So i decided to send this email instead. Is that a bug of the web interface? I dont remember a similar occassion in the past. Greg

1 1

Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
by RedShift 09 Jul '08

09 Jul '08

Thomas Bächler wrote: > Andreas Radke schrieb: >> It's more a question what Arch64 was founded for: to be the bleading >> edge leading _pure_ 64bit distro around. That's been its goal since the >> project has started. And I think we did a good job. >> >> You may have missed the early discussions when we made decisions that >> we don't want (though we have could have) multilib compatibility and >> bi-arch gcc. That was a strict law. It was our way to push the efforts >> to once get it the same level where the x86 world is. > > I missed the discussions, maybe. But this is not a discussion we had a > few years ago, this is the discussion we are having now. And just saying > "A few years ago, we wanted it this way" is not a good reason. > >> Offering 32bit compat stuff always means to make it easy for users > > No, not to make it easy, but make it possible. As I said in my reply to > Daniel, I need a 64 bit OS, but I also need mixed 32/64 bit environments. > >> but takes much pressure from companies and opensource developers give >> the x86_64 architecture the time and responsibility it is worth. You >> can compare it to the question to support closed source stuff or not. >> We made our decision long ago. So please respect it. > > We never denied closed source software out of principle. We always made > things "just work". I want standard applications to "just work", without > having to bother about which architecture I am on. > > Now, again, you gave me a list of ideological reasons not to do it, but > where exactly is the point where this damages your "pure" system > technically? > It's about the technical purity. It's this that makes us different from the other distro's. Otherwise we're just on the road to the next ubuntu. And if you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and don't bother with the multilib stuff. Glenn

4 3

Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
by Loui 08 Jul '08

08 Jul '08

On Tue, Jul 08, 2008 at 02:25:44PM -0500, Aaron Griffin wrote: > I have to side with Thomas here on the fact that no technical > arguments were brought up. That irks me just a bit - that "no because > no" seems to be a valid reason. It's not. > > That said, I am very very neutral on this. Thomas' plan does not > integrate anything at all, it just puts some 32bit libs in a parallel > repo for people to use if they want to (read: users can choose). A > pristine system is all well and good, but as we can all tell from the > existence of the lib32- packages in community, it's not what everyone > wants. What Thomas is proposing is keeping the pristine system > pristine unless someone wants to install the 32bit stuff. I don't have > a problem with this rationale. > > *But* I think it is a bit important that we look at why we're doing > this - for a handful (5 or 6) closed source apps. flash, teamspeak, > skype, google-earth (and wine). It seems like a lot of work for a > handful of apps. That's why I'm neutral on this. I think the rationale > is sound, but it sounds like a lot of forward MOTION for little > forward PROGRESS. Well there's nothing stopping people from creating their own 32bit library repos for x86_64. So just get together and do it eh? That's why there are things like kdemod and a new arch-games repo.

1 0