- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] makepkg.conf settings - Was:[signoff] pacman 3.3.0
by Gerardo Exequiel Pozzi 03 Aug '09

03 Aug '09

Allan McRae wrote: > Dan McGee wrote: >> Allan (and others)- I added a carbon copy version of makepkg.conf to >> SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity >> check policy? >> > > Here go my recommendations: > > 1) Arch LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed > There are very few problems with --as-needed these days and several > other distros are using it to. You can always do an somthing like > export LDFLAGS="" if it fails (much like is done when our CFLAGS cause > issues. The -Wl,--hash-style=gnu will cause us not to have sysv > hashes in our packages (we currently patch gcc to have both so > building without makepkg will be unaffected). > > For LDFLAGS agree with you, but maybe is secure to also add -Wl,--no-undefined , so I guess the linked can report undefined symbols in regular object files. (I can't remember now, but without this flag and with --as-needed some packages not build, but this was before the recent as-needed patch to binutils) I think that is sane to add to CFLAGS -Wall (and with more reason with latest gcc, and only produce more/equal build msg output), why this? Many apps already setup this flag in Makefiles, but others no. Do you remember the issue with mysql corruption because strict-aliasing? This can be detected at build time if -Wall was present. Of course at this time many packages are rebuilded, but only god knows what os these have an strict-aliasing issue, and is problematic. My two cents, -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.3.0
by Gerardo Exequiel Pozzi 03 Aug '09

03 Aug '09

Dan McGee wrote: > Signoff for pacman/makepkg 3.3.0. Notable things: > > * once this goes in, we can officially start doing split packaging and > build()/package() usage in our PKGBUILDs. > * this is basically a signoff for libfetch too, and you can remove > libdownload from your system. > > Allan (and others)- I added a carbon copy version of makepkg.conf to > SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity > check policy? > > -Dan > > oops! pacman-3.3.0-1-i686 : makepkg.conf looks bad CARCH="x86_64" CHOST="x86_64-unknown-linux-gnu" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe" -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

Re: [arch-general] How does pacbuild work?
by Dominik Schips 02 Aug '09

02 Aug '09

Hello Allan, Am Sonntag, den 02.08.2009, 19:45 +1000 schrieb Allan McRae: > > Maybe I can make it direct accessible but first I want to know > > if it is really necessary. > > FYI, I have not seen talk about this in a couple of years. So I guess > this project got disbanded. Ok, thank you for this information and the fast reply. Thought Arch Linux is using build farms for all the packages to build after I read about pacbuild in the wiki. -- Best regards Dominik Schips

1 0

[arch-general] How does pacbuild work?
by Dominik Schips 02 Aug '09

02 Aug '09

Hello, I want to know if it is necessary for pacbuild (strawberry daemon) to be accessible direct by IP/DNS of the apple daemon? As I read here http://wiki.archlinux.org/index.php/Pacbuild_Explained I thing it should be direct acessible but I am not sure. "Apple is the main server. PKGBUILDs are submitted here, and apple does the dirty work of contacting build machines and telling them to do work." The problem is that the possible build machine (x86_64) I want to offer the project is in a DMZ which is not direct accessible. Only outgoing traffic is allowed. Maybe I can make it direct accessible but first I want to know if it is really necessary. -- Best regards Dominik Schips

2 1

Re: [arch-general] Xorg broken after last update
by Luís Moreira 01 Aug '09

01 Aug '09

On Sun, 2 Aug 2009 00:28:42 +0200 Edgar Kalkowski <eMail(a)edgar-kalkowski.de> wrote: > Hi, > > I somewhere read something about the latest nvidia driver being > broken for notebook chips. I’m not sure if this is correct or was > just an issue with the beta drivers but especially as you mention > that it worked again after changing to vesa drivers I thought this > might be the case here. > > I’m using nvidia drivers for my notebook as well but have not yet > updated them because I read that it might cause problems. Are you, > too, running a notebook? If so I’d be interested to hear if the > latest nvidia drivers work ok for you. > > Edgar > > > > Am oder ungefähr am Samstag, 01. August 2009, um 23:58:58 schrieb > Luís Moreira: > > Hello. > > > > The last update broke my Xorg, the screen just goesn black and hangs > > there, CTRL+ALT+F1 (etc) doesn't do anything. > > > > I'm using X86_64, *without* [testing]. > > > > The updated packages were > > > > kernel26 > > nvidia > > xorg-server > > (and some others, less important) > > > > If I change the driver in xorg.conf from nvidia to vesa X works > > again. > > > > Anyone experienced the same thing? > > > > Best regards, > > Luís Moreira. > > Correct, I'm using a laptop with a NVIDIA GEFORCE GO 7300 graphics card. On Sat, 1 Aug 2009 15:33:33 -0700 Giovanni Scafora <giovanni(a)archlinux.org> wrote: > 2009/8/1, Luís Moreira <lmm1987(a)gmail.com>: > > nvidia > > Are you using nvidia-185.18.31-1? > > Yes, I updated to that version, the latest ones. Best regards, Luís Moreira.

1 0

[arch-general] postgresql 8.4
by Caleb Cushing 01 Aug '09

01 Aug '09

what's the status of getting this into extra's? all it seems to require is a typical version bump (outside of the xml bug). It appears to work ok on x86_64 on my system. although I haven't done super thorough testing. -- Caleb Cushing http://xenoterracide.blogspot.com

2 1

Re: [arch-general] [arch-dev-public] news item draft: /dev layout cleanup
by Gerardo Exequiel Pozzi 01 Aug '09

01 Aug '09

Allan McRae wrote: > Hi all, > > Getting around to this again.... > > [draft] > /dev layour cleanup > > The /dev layout has been cleaned up to comply to the device names > specified in the Linux kernel documentation. We had some legacy left > from our devfs days, which has now been removed. > > The most obvious change from a users perspective is the vc/*->tty* > transition. The initscripts-2007.08 update requires adjusting the > /etc/inittab file to refer to tty* instead of vc/*. Due to severe > system breakages if this file is not updated, this change will be > automatically handled by pacman. The original /etc/inittab file is > saved as /etc/inittab.pacsave. To be clear: > > package /etc/inittab -> inittab.pacnew (if needed) > system /etc/inittab -> inittab.pacsave > system /etc/inittab --sed--> inittab > > Make sure to check these files after the update and do any merging > that is required. > [/draft] > * If and only if, user touched /etc/securetty (from 'filesystem'), also must be edit manually it again to match /etc/securetty.pacnew, so I think that is more safe to add to the announce mail. * Also note the importance of update all packages 'initscripts' 'filesystem' 'udev' 'syslog-ng' at the same time. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

Re: [arch-general] [arch-dev-public] news item draft: /dev layout cleanup
by Rogutės Sparnuotos 01 Aug '09

01 Aug '09

Allan McRae (2009-08-01 22:33): > Hi all, > > Getting around to this again.... > > [draft] > /dev layour cleanup > > The /dev layout has been cleaned up to comply to the device names > specified in the Linux kernel documentation. We had some legacy left > from our devfs days, which has now been removed. > > The most obvious change from a users perspective is the vc/*->tty* > transition. The initscripts-2007.08 update requires adjusting the > /etc/inittab file to refer to tty* instead of vc/*. Due to severe > system breakages if this file is not updated, this change will be > automatically handled by pacman. The original /etc/inittab file is > saved as /etc/inittab.pacsave. To be clear: > > package /etc/inittab -> inittab.pacnew (if needed) > system /etc/inittab -> inittab.pacsave > system /etc/inittab --sed--> inittab > > Make sure to check these files after the update and do any merging that > is required. > [/draft] > > Finally, are we going to do a quick update to initscripts and filesystem > before this is moved? There have been a few patches push to get for > these. I can do that tomorrow if people agree? > > Allan As someone has already mentioned, it would be nice to mention the reasons for this (vc/*->tty*) change to please curious users... Why is this needed? Are /dev/vc/* going away? -- -- Rogutės Sparnuotos

2 1

[arch-general] Arch doc inclusion policy
by Sven-Hendrik Haase 01 Aug '09

01 Aug '09

Hey everybody, looking through my /usr/share/doc today I noticed that there were surprisingly few packages that actually installed their documentation there. Not even the SDL package installed its docs in there. I don't mind this too much as I carry all kinds of library documentation in my home directory with me at all times to have it accessible when I have no Internet connection available. This left me wondering, though, what Arch's general policy is on inclusion/exclusion of library/tool/package documentation for /usr/share/doc and if this policy should be generally applied to AUR packages as well. -- Sven-Hendrik

2 1

[arch-general] how to migrate installs between hard drives?
by Will Siddall 01 Aug '09

01 Aug '09

I know this isn't particularly an arch question, but I know Arch people are better off to ask then most. I'm in the process of upgrading my hard drive in my laptop but with the amounts of customizations I've done to my setup, I don't want to have to set it all up again. I know about running dd to copy the partition information, but the problem with that is that it also copies that partition information over. So, if I copy my root partition that started as a 40G partition with 90% used and now I have a 60G parition, the used portion will be kept at 90% so, it'll show something like 50G of data... which doesn't make sense. I've also just tried copying the partitions to an external, mount the iso's in a livecd session then copy the data over, but for some reason after I modified the menu.lst and fstab files to match my new setup and then restart, the computer doesn't boot. Is there something I'm missing in the second instance that I didn't change a file that should be changed? Is there a better way of copying the partitions so I don't run into this problem? Thanks, Will

26 44

[arch-general] [signoff] kernel26 2.6.30.4-1
by Tobias Powalowski 31 Jul '09

31 Jul '09

Hi guys, just an upstream bump. please signoff fast greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-general] community svn issues
by Allan McRae 31 Jul '09

31 Jul '09

Hi, The following packages have files in the wrong place in svn. Something like <pkg>/repo/<pkg> instead of <pkg>/repo/<pkg>-<arch>. cabal-install codeblocks haskell-x11 haskell-zlib moovida Also python-matplotlib has a package in "comunity-i686". I will fix these up but please remove any stray files as they cause issues for the ABS scripts. Thanks, Allan

2 1

[arch-general] Emacs 23 window resize on startup
by Edgar Kalkowski 31 Jul '09

31 Jul '09

Hello list! I know this is not an Arch specific question but I thought maybe something similar occurred to someone here and he knows a solution. I just updated to Emacs 23 which has new fancy font code with antialiasing etc. However the default font of 12pt is way too big for my taste. So I changed it to 10pt and saved the configuration to my ~/.emacs file. Everything works fine -- the font is smaller now -- but: Every time I start Emacs now the window first resizes to the dimensions that would be needed by the old (bigger) font. The (yet empty) window is then displayed and layouted by the window manager (KDE 4’s kwin). I configured it to center all new windows by default because I like it that way. Then the Emacs window resizes itself to match the new (smaller) font and the window is no longer centered! This may seem like a minor issue and I know it is. But it nevertheless annoys me and I did not find a way to change this behaviour! Is there a way to do so? Emacs should just first resize the window to match the font size the user has actually configured and then display the window! Greetings! Edgar

5 8

[arch-general] abs issues
by Sascha Siegel 31 Jul '09

31 Jul '09

hi, "sudo abs" deletes the repos core, extra and testing and creates "comunity" AND "community". i think theres something wrong with the abs-sync. /etc/abs.conf says: REPOS=(core extra community testing) but ls on /var/abs sais: community comunity local README tryed differend servers. no success ;\ someone have the same problem? greetings

3 2

[arch-general] archboot stills depends of portmap
by mathieu p 30 Jul '09

30 Jul '09

Maybe someone should fix that, since portmap has been replaced by rpcbind some time ago (and portmap can no longer be found on any repo). (archboot is in [extra] )

5 9

Re: [arch-general] [arch-dev-public] [signoff] grub-0.97-16
by Gerardo Exequiel Pozzi 30 Jul '09

30 Jul '09

Ronald van Haren wrote: > It's time for the 16th release in the grub 0.97 series. Grub 0.97 is > now allowed to have drinks ;-) > > This release fixes FS#14363. The old inode patch caused in some > circumstances a division by zero which is no good, the new patch fixes > this. > > In testing for both architectures. Please signoff. > > Ronald Sign-off i686 and x86_64 Reinstalled grub via grub-install /dev/sda (i686) and grub-install /dev/sdd (x86_64) Both systems boot OK. FS: EXT3 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

[arch-general] Run commands as user once network is up (NetworkManager)
by Magnus Therning 30 Jul '09

30 Jul '09

I'm currently using NetworkManager's ability to run scripts once the network is up[1], but that seems to only be on a system level. Is there some way of also running scripts/programs as the logged in user once network is up? Especially I want to start dropbox only when the network is available. It seems completely incapable of coping with a network that appears after it's been started. /M [1]: I've put a short script in /etc/NetworkManager/dispatcher.d/ that will start and stop openntpd when the network goes up and down. -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 1

[arch-general] vim syntax file broken??
by David C. Rankin 30 Jul '09

30 Jul '09

Listmates, Attempting to enable syntax in vim, I received the following: Error detected while processing /usr/share/vim/vim72/syntax/syntax.vim: line 42: E216: No such group or event: filetypedetect BufRead Press ENTER or type command to continue It has always worked before, so this is something new. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

3 3

[arch-general] where is xorgversion.m4
by David C. Rankin 30 Jul '09

30 Jul '09

Listmates, I can't build the radeonhd driver any longer due to a missing xorgversion.m4. I have both m4 1.4.13-1 xorg-util-macros 1.2.2-1 installed but I can't find the xorgversion file. Any ideas? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 1

[arch-general] pppoe-start resets eth0 MTU
by b4283 30 Jul '09

30 Jul '09

Hi, I usually set my eth0 adapter's MTU value to 7200 to get reach of Jumbo Frame function of my hub. But after I run pppoe-start (comes from rp-pppoe), it seems that the program will automatically reset the MTU value of eth0 to 1500, which is a big bugger. Does anyone know how to prevant this from happening that I wouldn't have to run "sudo ifconfig eth0 mtu 7200" again? -- b4283.

1 0

[arch-general] Latest updates messed up kdemod3 libjpeg.so.62?
by David C. Rankin 29 Jul '09

29 Jul '09

Listmates, Up until this past week kdemod3 and kde4-unstable had lived side-by-side quite harmoniously. However, now kcontol in kdemod3 will not run until the following link is created: ln -s /usr/lib/libjpeg.so.7 /usr/lib/libjpeg.so.62 After the link is made, kcontol will start, but any attempt to access the panel or taskbar settings (among others) results in a complete kcontrol crash. The backtraces are generally the same: [KCrash handler] #5 0x0000000000000000 in ?? () #6 0x00007f3a2e4f29b5 in jpeg_CreateDecompress () from /usr/lib/libjpeg.so.62 #7 0x00007f3a2d92de78 in ?? () from /opt/qt/plugins/imageformats/libqjpeg.so #8 0x00007f3a337d32f9 in QImageIO::read () from /opt/qt/lib/libqt-mt.so.3 #9 0x00007f3a337d3696 in QImage::load () from /opt/qt/lib/libqt-mt.so.3 #10 0x00007f3a2a9e1b3d in KBackgroundRenderer::doWallpaper () from /opt/kde/lib/kde3/kcm_kicker.so #11 0x00007f3a2a9e270a in KBackgroundRenderer::render () from /opt/kde/lib/kde3/kcm_kicker.so #12 0x00007f3a2a9e2a28 in KBackgroundRenderer::qt_invoke () from /opt/kde/lib/kde3/kcm_kicker.so #13 0x00007f3a337fd3cf in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #14 0x00007f3a337ff726 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #15 0x00007f3a3381d8a5 in QTimer::event () from /opt/qt/lib/libqt-mt.so.3 #16 0x00007f3a3379fc75 in QApplication::internalNotify () from /opt/qt/lib/libqt-mt.so.3 #17 0x00007f3a337a0dca in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3 #18 0x00007f3a34f91ee2 in KApplication::notify () from /opt/kde/lib/libkdecore.so.4 #19 0x00007f3a33796353 in QEventLoop::activateTimers () from /opt/qt/lib/libqt-mt.so.3 #20 0x00007f3a337517b8 in QEventLoop::processEvents () from /opt/qt/lib/libqt-mt.so.3 #21 0x00007f3a337b6609 in QEventLoop::enterLoop () from /opt/qt/lib/libqt-mt.so.3 #22 0x00007f3a337b64c2 in QEventLoop::exec () from /opt/qt/lib/libqt-mt.so.3 #23 0x00007f3a2f0555fa in kdemain () from /opt/kde/lib/libkdeinit_kcontrol.so #24 0x00000000004076e8 in ?? () #25 0x0000000000407e85 in ?? () #26 0x0000000000408562 in ?? () #27 0x0000000000408ea4 in ?? () #28 0x00007f3a313d69ed in __libc_start_main () from /lib/libc.so.6 #29 0x0000000000404549 in ?? () #30 0x00007fff9c658818 in ?? () #31 0x000000000000001c in ?? () #32 0x0000000000000005 in ?? () #33 0x00007fff9c659ad5 in ?? () #34 0x0000000000000000 in ?? () Do I need to create another link or a different link to solve this problem. Also, where should this bug report go? Chakra or Arch? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

8 11

[arch-general] VirtualBox keeps crashing
by Tim Gelter 29 Jul '09

29 Jul '09

Hello listmates, I'm having semi-frequent virtualbox crashes with existing and newly created virtual machines. Here is a snippet from /var/log/kernel.log : Jul 29 08:24:17 guapArch kernel: VirtualBox[5142] trap int3 ip:7f7dde81dd9a sp:7f7dd003bf00 error:0 Jul 29 11:38:43 guapArch kernel: VirtualBox[6559] trap int3 ip:7f4bcedacd9a sp:7f4bc0b74f00 error:0 Jul 29 11:56:47 guapArch kernel: VirtualBox[6589] trap int3 ip:7f1fd205ad9a sp:7f1fc4622f00 error:0 Jul 29 13:47:46 guapArch kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Jul 29 14:08:30 guapArch kernel: VirtualBox[7034] trap int3 ip:7f8f29938d9a sp:7f8f154e3f00 error:0 I've googled around a bit and don't see anything anywhere. Do any of you happen to have any ideas as to what is going on here? root ~ # pacman -Q virtualbox_bin virtualbox_bin 3.0.2-2 root ~ # uname -r 2.6.30-ARCH root ~ # pacman -Q kernel26 kernel26 2.6.30.2-1 root ~ # pacman -Syu :: Synchronizing package databases... core is up to date extra is up to date community is up to date kdemod-core is up to date kdemod-extragear is up to date kdemod-playground is up to date :: Starting full system upgrade... local database is up to date Thanks! Tim

2 2

[arch-general] lddd from devtools rewritten
by clemens fischer 28 Jul '09

28 Jul '09

I rewrote lddd from extra/devtools. The intent was to make it faster and remove false positives, as well as support for ignoring certain files completely, filtering the list of missing libs to handle optional dependencies, take /etc/ld.so.conf into account and in general make it more usable. NB: uses bash-4 features. URL: http://ino-waiting.gmxhome.de/files/lddd-c.sh Here's the help screen: $ lddd-c.sh -h Use lddd-c.sh [options] [paths] Default-paths: $PATH, /lib:/usr/lib:/opt/qt/lib:/opt/kde/lib:/usr/lib/libfakeroot:/opt/NX/lib:/usr/local/lib:/usr/local/libexec options: -d <item>: do not check glob <item>, can be given multiple times. -l <item>: ignore missing library glob <item>, multiple times. -L: do not use LD_LIBRARY_PATH running ldd(1)[1]. -v: be more and more chatty. -D <glob>: trigger tracing on meeting <glob>, debugging aid. Environment variables: $LDDD_LIB_IGNORE: globs of missing lib-names to ignore[2]. $LDDD_DONT_CHECK: globs of file names to completely ignore[2]. [1] risks false positives, but finds all broken ELF dependencies. [2] space separated list of globs, needs to be quoted to the shell. NB: A broken ELF file will be reported unless it is ignored ('-d' option or $LDDD_DONT_CHECK) or _ALL_ of its missing libs are ignored ('-l' or $LDDD_LIB_IGNORE)! _version: 20090727-2016_ The "new and improved" algorithm goes like this: 1. All files executable by the user or matching the customary *.so patterns are collected after verifying their ELFness. 2. The file paths are checked to see if their base directories contain any libraries and these directories are collected into LD_LIBRARY_PATH. 3. In a third loop, the files from step one are checked by ldd(1) prefixed with this LD_LIBRARY_PATH to see if any prerequisites are missing. This step is repeated without the path to check the odd customer. 4. Suspects aquired this way are sent to a co-process to determine the packages they belong to. 5. Results are collected into files in /tmp/lddd-c.sh-$UID and a summary listed to stdout. This makes it easy to use in cron-jobs. Detail is controlled by the number of '-v' options. Step four was intended to speed up the process, but as it turns out it doesn't help all that much. The pacman call is indeed expensive and can be done in parallel, but it obviously competes for disk access. Therefore the co-process caches the file list of any broken package expecting to find more broken files in it, but this only helps big packages with several broken executables. All in all lddd-c.sh is an improvement over the simpler lddd and the terribly hacked findbrokenpkgs[1]. As there should be no false positives, it should report b0rked packages after botched or incomplete updates in a reliable way. Valuable testing was done by Allan McRae and AttilaH. Some nasty bugs would still stink the code without their patience. [1] http://bbs.archlinux.org/viewtopic.php?id=13882 clemens

1 1

[arch-general] What? - NO 'p' in dmraid-1.0.0.rc15-8 anymore?
by David C. Rankin 28 Jul '09

28 Jul '09

Listmates, After going through the testing process with dmraid-1.0.0.rc15 where the biggest change for users was the addition of the 'p' in the /dev/mapper/raidname_device_partx naming convention, the last update warns that you must now *remove* the 'p' from fstab, etc.. What's up? Will we have to add the 'p' again next week? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 1

Re: [arch-general] [arch-dev-public] [signoff] ed 1.4-1
by Gerardo Exequiel Pozzi 28 Jul '09

28 Jul '09

Roman Kyrylych wrote: > On Tue, Jul 28, 2009 at 21:52, Eric Bélanger<snowmaniscool(a)gmail.com> wrote: > >> On Tue, Jul 28, 2009 at 10:27 AM, Ronald van Haren<pressh(a)gmail.com> wrote: >> >>> On Sun, Jul 26, 2009 at 8:59 PM, Andreas Radke <a.radke(a)arcor.de> wrote: >>> >>>> minor upstream update. please signoff. >>>> >>>> -Andy >>>> >>>> Changes in version 1.4: >>>> >>>> >>>> * The undo command has been fixed to restore the modified status of the >>>> buffer being edited. >>>> >>>> * A race condition with user interrupt has been fixed in >>>> search_and_replace. >>>> >>>> * The functions resize_line_buffer and resize_undo_buffer have been >>>> added to definitively fix the aliasing warnings. >>>> >>>> * Some minor corrections have been made to the manual. >>>> >>> It still fires up and displays a simple txt document, haven't tested >>> anything fancy though. >>> signoff i686 >>> Ronald >>> >> signoff x86_64 >> > > signoff['x86_64']++ > > > Sign-Off i686 Manual pages are OK Info pages are not compressed. (pending for next pacman) but... $ ed a i can't still import my office2007 documents here!!! I am desesperate! . w tested 72 q $ -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0