Bug#413469: bug 413469
On 2007-03-14 19:58 -0400, Michael Gilbert wrote: just set up a mailer auto-reply that says i do not support out of date ion3 development snapshots and will not respond to mails unless the first line contains the output of 'ion3 --version' And how would I do that? I get other mail besides Ion mail, you know. with that said, i agree that in-development snapshots should be kept out of unstable, and only done in experimental. maybe this should be a change to debian-policy? Nah, dev. snapshots can be in testing/unstable.. but should never get into stable... unless, of course, through an additional package collection for it (backports), that does keep upgraded. -- Tuomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413469: Please don't, there are people using it
On 2007-03-11 01:19 -0800, Frank Bauer wrote: I do understand that Ion3 is not finished yet and you as the author of this gem should know the best when the software is stable, but as I mentioned earlier, some features from Ion3 are huge usability improvement over Ion2 and current snapshot of Ion3 in Etch (and also in Sarge) does everything I need. Maybe it does what you need, and you are one of the few who know not to complain, when it doesn't. But how about the newbies that have just heard of Ion3, and 'apt-get install ion3' gets them an old unsupported version that doesn't work for them? It's them whom I'm concerned about -- and they do exist. And, as has been mentioned, the upgrade path from the version in sarge -- that also should never have been there -- to the newer releases is not straightforward. There are also going to be incompatibilities between even those releases and the stable ones. Do you want to spend time rewriting your configs once again, when the stable ion3 finally hits a stable Debian, years from now? Do you like not being able to use any new scripts in the ion3 scripts repository, because they will not work with your old release? The megafreeze just doesn't work. -- Tuomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413469: Please don't, there are people using it
This is quite unfortunate for me. I, for one, am using officially packaged Ion3 on current stable and intended to use Ion3 also in upcomming Etch. I can't be bothered to install all those development packages just to compile the curent versions Why do you want a random broken and unsupported development snapshot? Can't you wait until a stable Ion3 is released (not that far away -- might even happen before Etch is released, depending on how things proceed), and install it by whatever means? Why can't people trust the upstream to decide, when the software is stable, and insist on using (mega)frozen development snapshots? -- Tuomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413469: Bug#413686: Bug#413469: ion3: The package is outdated
On 2007-03-07 19:54 -0500, Clint Adams wrote: This would mean that any sarge users upgrading to etch would be stuck at ion3 20050502 instead of 20061223. Is that preferable to allowing fresh installs to have ion3? Yes: at least there won't be new users with ancient releases. -- Tuomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370764: xorg: The paths are all fucked up
Package: xorg Version: 1:7.0.20 Severity: critical Justification: breaks the whole system Thank you very much for moving everything from under /usr/X11R6 to the mess known as the /usr hierarchy. Now nothing works. After spending a lot of time to even manage to get X install after upgrade _removed_ all of X and x11-common refused to install at all (needed a kludge that looped creating symlinks from /usr/lib and /usr/include to /usr/X11R6 for it to not die in install scripts -- where's the option to just fucking unpack it and mark installed?), X now crashed (didn't reboot it afterwards, because I know this was coming). And now I can't boot it, because I can't install the nvidia driver. And all the other configs are fucked up too, because things are all over the place. You don't just go removing such an _established_ directory as /usr/X11R6 that all programs expect, and putting everything in a single basket. That's, indeed, the completely wrong direction to take. Application directories (/usr/pkg/package-version/ or maybe even /debian-testing/packag-version/) are the way to go, not taking this unix all in one basket mess even further. Now I hear everyone complaining you shouldn't be running testing if you're not willing to go through all the trouble. Yeah, maybe I'll have to switch GoboLinux, for at least they're attempting at cleaning up things with app.dirs instead of the FHS idiocy (/media sucks too BTW; removable media should reside directly under root for comfortable names -- and symlinks aren't of much help there generally), although They Have Been Corrupted By The Marketdroid Conventiong Of Very Long and Cumbersome Names. Or maybe I should switch to Windows, for Linux keeps getting worse all the time, and on Windows at least there Firefox has a semi-usable file dialog, and I can could use a free browser. Wait... Opera also is not an option anymore as I have no functioning X. Thank you very much. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=C, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages xorg depends on: ii aterm [x-terminal-emulator] 1.0.0-2Afterstep XVT - a VT102 emulator f ii eterm [x-terminal-emulator] 0.9.3-1Enlightened Terminal Emulator ii libgl1-mesa-dri 6.4.1-0.4 A free implementation of the OpenG ii libgl1-mesa-glx [libgl1-mesa- 6.4.1-0.4 A free implementation of the OpenG ii libglu1-mesa 6.4.1-0.4 The OpenGL utility library (GLU) ii mlterm [x-terminal-emulator] 2.9.2-5+b1 MultiLingual TERMinal ii rxvt [x-terminal-emulator]1:2.6.4-10 VT102 terminal emulator for the X ii rxvt-unicode [x-terminal-emul 7.7-4 RXVT-like terminal emulator with U ii xbase-clients 1:7.0.1-2 miscellaneous X clients ii xfonts-100dpi 1:1.0.0-2 100 dpi fonts for X ii xfonts-75dpi 1:1.0.0-2 100 dpi fonts for X ii xfonts-base 1:1.0.0-3 standard fonts for X ii xfonts-scalable 1:1.0.0-4 scalable fonts for X ii xkb-data 0.8-5 X Keyboard Extension (XKB) configu ii xserver-xorg 1:7.0.20 the X.Org X server ii xterm [x-terminal-emulator] 210-3 X terminal emulator ii xutils1:7.0.0-3 X Window System utility programs xorg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295213: general: Upgrade removed /usr/local (symlink)
Package: general Severity: grave Justification: causes non-serious data loss Apt-get upgrade just moments ago removed my /usr/local/ symlink and replaced it with a hierarchy of empty directories. The contents of the proper /usr/local/ on another disk seem to be intact. The contents of the new /usr/local/ after the upgrade: ~$ find /usr/local/ /usr/local/ /usr/local/lib /usr/local/lib/python2.3 /usr/local/lib/python2.3/site-packages /usr/local/lib/python2.1 /usr/local/lib/python2.1/site-packages /usr/local/lib/python2.2 /usr/local/lib/python2.2/site-packages /usr/local/lib/xemacs /usr/local/lib/xemacs/site-lisp /usr/local/share /usr/local/share/emacs /usr/local/share/emacs/site-lisp /usr/local/share/emacs/21.3 /usr/local/share/emacs/21.3/site-lisp /usr/local/share/zsh /usr/local/share/zsh/site-functions -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1 (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
