[Bug 1594035] Re: unable to shut down the system after suspend / resume
Correcting error: "This is so no matter which path to the swap partition I use, including: /dev/disks/by-uuid/, the device show by "grep /proc/swaps", or /dev/mapper/cryptswap1." ๐ฆ๐ต๐ผ๐๐น๐ฑ ๐๐ฎ๐: "This is so no matter which path to the swap partition I use, including: /dev/disks/by-uuid/, the device show by "๐ฐ๐ฎ๐ /proc/swaps", or /dev/mapper/cryptswap1." -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594035 Title: unable to shut down the system after suspend / resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1594035/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594035] Re: unable to shut down the system after suspend / resume
Being a fellow pilgrim in the Way of the Penguin, I can confirm the exact same facts as Mr. Pellegrino on clean install of Ubuntu Mate 16.04. It appears that the swap partition is not actually encrypted at all. Syslog shows that encryption failed, and "cryptsetup -v isLuks /path/to/partition" shows not LUKS partition. This is so no matter which path to the swap partition I use, including: /dev/disks/by-uuid/, the device show by "grep /proc/swaps", or /dev/mapper/cryptswap1. Looking at /var/log/syslog, I see that cryptsetup failed because /dev/urandom is not available. ("grep crypt /var/log/syslog" for details.) Further, I notice that poweroff.target is disabled. When I enable it (systemctl enable poweroff.target), shutdown works as expected unless the computer has resumed from suspend. The work around suggested by Mr. Pellegrino works, but of course that means that swap is not encrypted, which is of course a security vulnerability. Here is my working theory: On boot-up, systemd tries to create an encrypted swap, but when it cannot, systemd creates an unencrypted swap. (Feature or bug? There would be competing considerations, so it is hard to say.) After resume from suspend, which of course involves (on suspend) writing RAM to swap and then (on resume) reading from swap to RAM, the system thinks there should be an encrypted swap (because that's what /etc/fstab and /etc/crypttab say), but can't find it and gets confused when time comes to shutdown. This being a security issue, it should be given attention. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594035 Title: unable to shut down the system after suspend / resume To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1594035/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs request focus too often
This is NOT a bug in metacity, nor in compiz. Almost two years ago, I described in this very thread what code should be changed to fix the bug. Loye Young loye.yo...@iycc.net 281-968-0828 On Wed, May 5, 2010 at 4:37 AM, Vish wrote: > Omer , Thanks for comfirming. > > As Mentioned earlier , this bug with metacity[no visual effects] has > been fixed a while ago. > > Users noticing this bug with compiz are affected by Bug #391479 . > > ** Changed in: update-manager (Ubuntu) > Status: Incomplete => Fix Released > > ** Changed in: hundredpapercuts > Status: Incomplete => Invalid > > ** Changed in: metacity (Ubuntu) > Status: Incomplete => Invalid > > ** Description changed: > > When I click the Reload button in update-manager, the "Downloading > package information" progress dialog takes a few seconds to start, with > the main window's widgets disabled. In this case, I switch to another > application, and the download progress steals the window focus. If I > switch again to another window, the "building dependency tree" progress > dialog steals focus again. > > This is a bug in the metacity window manager. > + > + *** > + For users using metacity[no visual effects] this bug has been fixed a > while ago. > + > + Users noticing this bug with compiz are affected by Bug #391479 . > + > + *** > > -- > 'Downloading package information' and 'building dependency tree' progress > dialogs request focus too often > https://bugs.launchpad.net/bugs/35876 > You received this bug notification because you are a direct subscriber > of the bug. > -- 'Downloading package information' and 'building dependency tree' progress dialogs request focus too often https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 559770] Re: avahi-daemon should be downgraded to a recommends dependency
Avahi-daemon is a security risk and does allow crossing of privilege boundaries because it makes possible automatic connections among hosts on the network irrespective of the policies set up by network administrators. This is an argument that we went through in Hardy LTS. The compromise was to make avahi-daemon a recommends. This bug is a regression from Hardy LTS. Loye Young loye.yo...@iycc.net 281-968-0828 On Tue, Apr 13, 2010 at 10:58 AM, Jamie Strandboge wrote: > Thanks for taking the time to report this bug and helping to make Ubuntu > better. We appreciate the difficulties you are facing, but this appears > to be a "regular" (non-security) bug. I have unmarked it as a security > issue since this bug does not show evidence of allowing attackers to > cross privilege boundaries nor directly cause loss of data/privacy. > Please feel free to report any other bugs you may find. > > ** This bug is no longer flagged as a security vulnerability > > -- > avahi-daemon should be downgraded to a recommends dependency > https://bugs.launchpad.net/bugs/559770 > You received this bug notification because you are a direct subscriber > of the bug. > -- avahi-daemon should be downgraded to a recommends dependency https://bugs.launchpad.net/bugs/559770 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 559780] [NEW] avahi-utils should be downgraded to a Recommends dependency
Public bug reported: Binary package hint: system-config-printer System-config-printer-common *depends* on avahi-utils, even though configuring printers does not require avahi. In such a case, the correct dependency level is a *recommends*. In situations where avahi is not desired, whether because of security policy or out of performance considerations, removing avahi breaks system-config-printer-common, which breaks system-config-printer-gnome, which breaks ubuntu-desktop. In essence, the *depends* prevents removal of avahi without removing the desktop. This is a regression from Hardy LTS and was discovered when upgrading to Lucid LTS Beta 2. ** Affects: system-config-printer (Ubuntu) Importance: Undecided Status: New -- avahi-utils should be downgraded to a Recommends dependency https://bugs.launchpad.net/bugs/559780 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 559770] [NEW] avahi-daemon should be downgraded to a recommends dependency
*** This bug is a security vulnerability *** Public security bug reported: Binary package hint: avahi-utils Avahi-utils *depends* on avahi-daemon, but should only *suggest* avahi- daemon. Avahi-daemon should *suggest* (or at best *recommend* avahi- utils. In many situations (especially in a corporate heterogenous environment), it would be inappropriate for the host to advertise services, but the host should be able to discover services (e.g., most notably printing). Avahi-daemon advertises services on the host, but the utilities in avahi-utils are useful in situations when the host's services should not advertised. Consequently, avahi-utils should not depend on avahi-daemon. ** Affects: avahi (Ubuntu) Importance: Undecided Status: New ** Visibility changed to: Public -- avahi-daemon should be downgraded to a recommends dependency https://bugs.launchpad.net/bugs/559770 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 123713] Re: package description needs rewrite
@John Vivirito, TZ and Kecsap are on the right track. This bug is not about typos. This bug is about the substance of the description. -- package description needs rewrite https://bugs.launchpad.net/bugs/123713 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 123713] Re: package description needs rewrite
Point me to something, anything, that documents what ubufox does and I'll be happy to write a description. >it allows you to change settings in the advanced setting page "about:config" Firefox already allows changing settings in about:config, without ubufox. The question is what changes are made by ubufox. >We are pretty much unable to get less general since ubufox has default settings that we ship and there are way too many Saying that the package does too much to document is pretty lame, IMHO. Rather, it's even more important to document them. >It is not possible at this point to install firefox without GTK apps/libs since there is not yet a qt version. No one is suggesting to install firefox without GTK, and trying to write it in QT is silly. In fact, the problem isn't firefox at all. The description says that it's adding "apt support", but that description is misleading. The problem is the additional GNOME dependencies that apturl drags in. What's really going on is that ubufox depends on a GNOME graphical interface to the apt protocol. There are three alternative tacks to take. (1) If ubufox and apturl don't do anything that is specific to GNOME, drop the dependency on the GNOME packages in apturl; (2) Change apturl to a Recommends dependency rather than a Depends (which probably makes sense in any event); and (3) (germane to this bug report) Provide a more accurate description of what the apturl dependency does. E.g., "ubufox also depends on apturl, which is a GNOME graphical interface to the apt protocol allowing installation of software using a URL of the software repository." Again, if ubufox were documented somewhere, the community could help. -- Loye Young Isaac & Young Computer Company Laredo, Texas loye.yo...@iycc.net 956.857.1172 -- package description needs rewrite https://bugs.launchpad.net/bugs/123713 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 123713] Re: package description needs rewrite
John, For more guidance on this bug, you might also take a look at my comments here: https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/123713/comments/15. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- package description needs rewrite https://bugs.launchpad.net/bugs/123713 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 123713] Re: package description needs rewrite
On Fri, Apr 3, 2009 at 7:53 AM, John Vivirito wrote: > Can someone please give a detailed description of what they would like > to see what they do see and how they see it. If you want to see what the current package description looks like, type the following from a command line: # aptitude show ubufox The Hardy LTS release shows this: "Description: Ubuntu Firefox specific configuration defaults and apt support Extension package for Firefox provides ubuntu specific configuration defaults as well as apt support for firefox plugins/extensions. You can uninstall this package if you prefer to use a pristine firefox install." Unfortunately, because the package is undocumented, there is no way to tell you what should be in the description. I can tell you that the current description is completely unhelpful about what "ubuntu specific configuration defaults" means. In addition, reading the original report of this bug would give you some idea of what is desired. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- package description needs rewrite https://bugs.launchpad.net/bugs/123713 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 153727] Re: Ethernet device's number increases by one after every reboot
On Mon, Mar 23, 2009 at 7:56 AM, Scott James Remnant wrote: >If you think otherwise, please provide patches. I've already written in this thread how to fix the problem, but nobody seemed to be interested. Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- Ethernet device's MAC address changes (causing its device number to increase by one each time) https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 153727] Re: Ethernet device's number increases by one after every reboot
>I bet I'm not the only one on the list of >subscribers who thought this was a generic bug on this persistent- >net.rules behavior. I'll echo that. I can't see how this bug report is confined to a particular chipset. We at IYCC see the problem on several hardware configurations. It's really a generic problem that should be fixed generically. Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- Ethernet device's MAC address changes (causing its device number to increase by one each time) https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 341876] Re: [Feature Request] Setup WiFi
Take a look at the code for wicd (http://wicd.sourceforge.net/). It would be easier to integrate into oem-config. (I understand that replacing network-manager with wicd is probably Dead On Arrival, but the code base of wicd is instructive of a better way to handle the problem.) At IYCC, the wireless networking "Just Works" using wicd. Two clicks and you're connected. Configuration Note: We did make a simplifying adjustment to /etc/udev/rules.d/70-persistent-net-rules by setting all wireless interfaces to receive the name "wlan*" and hard coding wicd's configuration to automatically uses wlan0 and eth0. Unless the user has consciously set up a multi-NIC configuration, it "Just Works." Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- [Feature Request] Setup WiFi https://bugs.launchpad.net/bugs/341876 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 341879] Re: Keyboard screen is confusing to non-techies
On Fri, Mar 13, 2009 at 10:15 AM, Colin Watson wrote: > Dead keys is something that will probably be a bit more familiar to non- > English keyboard users, where the notion of a key you have to press > before another key in order to get a diacritic (e.g. ' then a -> รก) is a > bit more familiar. I am wary about changing this from a English-centric > point of view. Colin frames the issue well. Here on the US / Mexico border, we've come across this issue frequently, and we are still searching for a balanced solution. One adjustment that would help, perhaps, would be better nomenclature. To us gringos, a "dead" key means a key that doesn't work because it's broken. The install script for console-setup describes the AltGr and Compose keys, and gives a helpful explanations. (Try running "dpkg-reconfigure console-setup".) An explanation taken whole or in part from that script would be helpful, methinks. By the way, I personally like the manner in which console-setup guides the user in making the keyboard selection. I think it strikes the right balance between simplicity and flexibility. I am told, however, that some other people like simpler interfaces with fewer choices, so it's a judgment call. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net 956.857.1172 -- Keyboard screen is confusing to non-techies https://bugs.launchpad.net/bugs/341879 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 149042] Re: do-release-upgrade has no man page
On Wed, Nov 5, 2008 at 8:59 AM, Michael Vogt wrote: > Thanks for your bugreport. > > If someone comes up with a good draft for a manpage, I'm more than happy > to add it to the package. do-release-upgrade is one of the "Mystical Secrets from the Land of the Ubunteros." If anyone else knew what it did or how, maybe someone could and maybe even would write a manual page. At the risk of redundancy . . . The bigger issue, of course, is that packages should never be added to the repository without a meaningful manual page. If such were policy, the person who wrote the program and is adding it to the repository would write the man page while the program was fresh in his or her mind, which is the easiest time to write the page. -- do-release-upgrade has no man page https://bugs.launchpad.net/bugs/149042 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 153727] Re: Ethernet device's number increases by one after every reboot
>I just picked a >random one, but this could be configured to match your card, or network >requirements. Thanks for running with this Jack. IMHO, what you call a "horrible work-around" is on the right track to the correct solution. Is there a way to have it remember from the first time the system recognizes a valid MAC address? Maybe then a wag-and-a-poke script could run during system installation and maintain the correct, consistent, and globally unique MAC address. (Yeah, the way it's supposed to.) As I wrote before on this thread, this is a problem that was documented and solved 10 years ago. We really should follow the standard and do it "The Right Way(tm)". See http://tools.ietf.org/html/rfc2469. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- Ethernet device's number increases by one after every reboot https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315647] Re: [Feature Request] OEM config should have bulletproof X support
>Perhaps instead of putting the bulletproof X support in oem-config, >perhaps it would be better to have oem-config's GTK or KDE frontends >fall back to the debconf frontend if they failed. The devil is in the details, of course, but this might be a workable compromise. Thanks Mario. Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- [Feature Request] OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 148454] Re: console-kit-deamon spawns too many threads
Vladamir is exactly right. Kruft needs to stay off our systems. Besides, Microsoft and Macrovision have patents on bloatware, and they would be pissed if we infringed on their intellectual property. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://archive.iycc.net On Wed, Feb 25, 2009 at 8:55 AM, Vladimir wrote: > Jakob Unterwurzacher > This is a wrong question. The question should be like this: If there is a > utility with questionable benefits eating up unnecessary resources and doing > next to nothing, then why we should keep it there? > > If we accept the fact, that "it does not matter" we could quickly find > ourself literally buried under pile of similar garbage. Linux used to > be *small and efficient*. Please try keep it that way. > > -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 148454] Re: console-kit-deamon spawns too many threads
Rock on, Vlad! I'd like to take a look at your utility. It may be of use in other cases. Would you post the source code, or a link to where the code may be found? Thanks. Loye Young On Tue, Feb 24, 2009 at 3:47 PM, Vladimir wrote: > After seeing that the discussion goes nowhere and nobody in charge is > willing to do anything about this problem, I chose my own solution. It > is ugly, dirty, but it works for now. > > I wrote in C program with only one instruction: exit. I have replaced > the huge console-kit-daemon in /usr/sbin with this "program" and bingo. > It works. No more 60+ threads. And the funny stuff is here: System seems > to work just as before. In other words IT DOES NOT NEED FOR THIS > MONSTER. Console kit daemon is completely useless utility. > > For those of you, who want to "solve" this problem I am attaching here > my console-kit-daemon utility. Please keep in mind this is only > temporary solution and it is far from perfect. > > > -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315647] [NEW] OEM config should have bulletproof X support
>There really is a comprehension problem here. I understand you perfectly. Perhaps it is you are aren't comprehending what I am saying. >Like I said, the recovery media runs OEM config prepare in its post install scripts. I am aghast at how you suggest customers should be supported. Oem-config (or any portion) should NOT be on a customer's recovery media at all. A recovery media should be simply a desktop installation disk preconfigured to factory defaults. >yes by the first boot init script.that's >what needs the fallback support. That's the part that should NOT have "fallback" support. Instead, the factory should fix whatever causes the X server not to load. "Fallback" support in that situation just leaves the customer thinking that the OS sucks generally, instead of the more accurate perception that something is wrong with the particular machine configuration. Happy Trails, Loye Young -- [Feature Request] OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315647] Re: OEM config should have bulletproof X support
>Mario knows what he's talking about. Let's just say that Mario and I have a fundamental difference on how oem-config should work and what its scope should be. We at IYCC work with it every day, and we do not tolerate shipping a machine in the state Mario describes. This report should be marked invalid (or perhaps "will not fix") because it's a bad idea. As I said earlier in this thread, while I agree that oem-config should degrade more gracefully by providing more helpful error messages, the so-called "bulletproof X" would make matters WORSE. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- [Feature Request] OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315647] Re: OEM config should have bulletproof X support
No. That's not the how oem-config works. The end user SHOULD NOT run anything. Oem-config is a two-stage process. First, oem-config sets up an OEM user and configuration desktop so that the engineer can configure the machine. When the machine is configured and ready to ship, the engineer runs oem-config-prepare, which gets the machine ready for the customer. (The "Prepare for shipping to user" icon and related menu item simply invoke oem-config-prepare and confirm that the machine is ready to ship.) All the customer has to do is turn on the machine and everything is automatic. The user simply waits for the machine to ask for the basic configuration details. Behind the scenes, oem-config-first-boot deletes the oem user, sets up the new user, and hands over the system to gdm (for a gnome desktop) or kdm (for a KDE desktop). This "bug" should be marked as "Invalid". Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- [Featire Request] OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 317791] Re: oem-config-dm installer fails
On Fri, Jan 16, 2009 at 6:06 AM, Colin Watson wrote: > The traceback just indicates that X failed to start. I need to > investigate to figure out whether this is a problem with X or a problem > with oem-config-dm (it could be either). > @Colin King: Post the Xorg logfiles: /var/log/Xorg.0.log and /var/log/Xorg.0.log.old -- Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- oem-config-dm installer fails https://bugs.launchpad.net/bugs/317791 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315644] [NEW] OEM config should offer to purge extra language packages
>In the event that more than one language pack is preinstalled, I think >an option should be added to the end of the OEM config wizard to remove >extra language support. This should be pre-selected, but disableable by >OEMs who would prefer it not turned on by default. This is an excellent idea. The additional updates for unnecessary languages eat up bandwidth, further burden distribution servers, and inconvenience the customer at update time. We currently mitigate (somewhat) the problem in two ways: First, we ask the customer at order time what languages are desired, but that's not always possible to do, especially in a retail environment. (We also find that some customers are a tad defensive or subtly evasive when responding.) Second, we ship a DVD with addtional language packages relevant for the target market, but that's not an optimal customer experience. I'm not even sure that anyone ever looks at the documentation or the DVD anyway. >A small mouse over should explain a little better what the ramifications >would be as well as if possible the amount of disk space that would be >freed by removing extra language support. I like the concept, but a mouse-over would over-complicate things. (Not everyone is physically able to use a mouse, and not every consumer computer design contemplates one.) A concise sentence or two of explanation would appropriately and neatly fit in the existing dialog box. IMHO, the emphasis of that message should be on speeding up the update procedure and on conservation of network and server resources. The addtional hard drive space is trivial compared to the size of hard drives these days. Everyone hates waiting for updates, however, and no one likes paying for more bandwidth. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- OEM config should offer to purge extra language packages https://bugs.launchpad.net/bugs/315644 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 315647] Re: OEM config should have bulletproof X support
On Fri, Jan 9, 2009 at 8:22 PM, Mario Limonciello wrote: >What's the first >thing you do when you boot your computer from the factory? You run >oem-config... I don't know about other companies' practices, but no customer of IYCC has to run oem-config. We have already run oem-config-prepare before we ship the machine. Normal customers should simply turn on the computer, wait for the Xserver/GTK dialog to start, fill out the form, and then log in. Even on reinstallation, the customer should NOT be running oem-config unless the customer wants to join the ranks of the Linux Army. Oem-config is a tool for the OEM. Before the machine ever leaves the factory, oem-config-prepare should have already been run so that the machine is in a working state, ready for the customer to get to work. When the customer turns on the machine the first time, the system runs through its start-up scripts, one of the last of which is starting the Xserver. Because it is the first time the customer has turned on the machine, instead of running the gdm-chooser immediately, a GTK application runs that asks for a few pieces of information, the user is created behind the scenes, and finally the gdm-chooser (or other login screen) loads. If the machine is unable to complete the boot process enough to load the Xserver, the customer has a defectively or incompletely configured computer and should either call the OEM for support or return the system for a cheerful refund or exchange. The GTK application won't run without an Xserver running. The application assumes (rightly) that the system is configured well enough from the factory that the process is capable of completing all the steps necessary, all the way through to Xserver startup. (Although it is technically possible to run natively in graphics mode from the time the kernel is loaded, for reasons of reliability and maximum compatibility, that's not the current state of the art.) Recovery discs should not require a customer to go through oem-config, even on reinstalltion. The Right Way to support the customer is to send a factory-customized disc that contains a more traditional desktop installation script and some additional recovery tools. The factory already knows how the system is to be configured, so it should have already set up the preseed file with all the configuration options already set and included all the necessary packages. The customer should not have to think, and the install should "just work." Pre-configuring the system is what customers pay OEMs to do. The oem-config script is an aid to OEMs when engineering a custom system. If the system needs a re-installation, the customer should be guided through a very clean desktop installation process that doesn't require anything more than filling in customer-specific information. Back to the original issue of this bug report, I share your frustration with defectively designed or built monitors and other peripherals. I do believe that oem-config-firstboot should fail more gracefully and provide more helpful information. Having banged my head against a wall way too many times, however, I am steadfast in my conviction that oem-config failing over to "bulletproofX" would just be pouring water on a drowning man. Again, if there are OEMs that need or want additional assistance with engineering and installing systems, IYCC has a great deal of expertise in this area, much of which we give away for free. We welcome your call. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://start.iycc.net -- OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315647] Re: OEM config should have bulletproof X support
Example #2 is perhaps a bad example because recovery disks should NOT use oem-config, for this and many other reasons. However, I am sensitive to your example #1, and in particular to EDID problems. (Why is EDID so hard for monitor manufacturers to get right? The spec has been around plenty of time. But I digress.) I remain strongly convinced that starting the Xserver is a bad idea in that situation and would make debugging worse. If oem-config is bailing from the install, either it should do a better job of recovering or the install should NOT go farther. However, a middle ground is available. The messages given by the current oem-config in that situation are cryptic, not helpful, and terse. The messages should be more intelligent about reporting what went wrong, how to call for help, and (if available) instructions for recovering (e.g., it might be possible to run a command that would tidy up the installation or even fix the problem). While you're at it, have oem-config set up a "manufacturer data" file that the OEM could populate and that error messages could grep for support phone number, email address, etc. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://archive.iycc.net -- OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315646] Re: OEM config should offer support to show EULAs
I misspoke on my last message. The requested change in this report would violate the Open Source Definition (Section 9), not (necessarily) the Free Software Definition. -- OEM config should offer support to show EULAs https://bugs.launchpad.net/bugs/315646 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315646] Re: OEM config should offer support to show EULAs
I myself am a lawyer and agree that EULAs need to be better integrated into the entire ecosystem. I am highly skeptical that, if the issue were squarely presented, Texas and US Federal courts would enforce a license buried in the bowels of an operating system for which the user had no opportunity to review or consent before using the software. I am strongly convinced, however,that oem-config is the WRONG place to do it because only the user who happened to be turning on the machine the first time would have agreed to the *End User* License Agreement. In addition, placing EULA in oem-config would violate the Free Software Definition and would violate the GPL because it would force a user to agree to one license as a condition to using other software. "The Right Way" The better practice is to run the EULA script by the x-session-manager. The login manager (gdm, xdm, etc.) calls x-session-manager when the user logs in. X-session-manager, in turn, runs the scripts in /etc/X11/Xsession.d, which handle all sorts of preparations for the user session. This is how, for example, new users get their directories and get the default .gconf files, etc. The EULA script in /etc/X11/Xsession.d/ should fire off a window asking for consent to the EULAs. If the user did not consent to the licenses required for the system and the desktop to run at all, the login would exit and return the system to the login manager. With respect to other EULAs , the EULA script would add the user to a group with permissions to use the software. If the user did NOT agree, the user would not be added to that group, which would allow the user to proceed to use other software. IYCC is interested in developing a "EULA" package that "Does The Right Thing". If anyone would like to participate, please advise. By the way, we have debtagged every package in our default installation with the type of license that covers the package. We use the debtags to create a booklet with a copy of each license and a list of the packages covered by such package. The booklet ships with our product as an additional users manual. We will soon be making the debtags available for others. If you need them sooner, please advise. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://archive.iycc.net -- OEM config should offer support to show EULAs https://bugs.launchpad.net/bugs/315646 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 315647] Re: OEM config should have bulletproof X support
This is a very bad idea, and should NOT be implemented. OEM config SHOULD degrade to a command line if it does not complete correctly. In fact, the "bulletproofX" would make make it harder to debug and correct problems. If the system doesn't complete configuration of the system, the right way to debug and fix problems is from the command line, because the X display itself will obfuscate issues and interfere with the results of various debugging procedures. Worse, the changes made to the system by bulletproofX would introduce new problems to the final configuration, creating defects that may not be apparent until the customer begins using the system. "you get thrown into a root shell with no idea what's going on." Respectfully, if you don't know what's going on from the command line, you should be using the regular desktop installation CD instead. OEM config should NOT be used by anyone who does not understand how to engineer the box and fix things from the command line. If you are an OEM or system builder but don't have sufficient resources to engineer your product so that you can efficiently, the Canonical team provides such services. IYCC also provides backend technical service to OEMs, ODMs, and system builders. We are doing just that for Feral- Penguin of Australia. See http://www.feral-penguin.com.au. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://archive.iycc.net -- OEM config should have bulletproof X support https://bugs.launchpad.net/bugs/315647 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 182988] Re: udev renames wireless devices when using wlanconfig/ignores interface names given to wlanconfig
*** This bug is a duplicate of bug 153727 *** https://bugs.launchpad.net/bugs/153727 ** This bug has been marked a duplicate of bug 153727 Ethernet device's number increases by one after every reboot -- udev renames wireless devices when using wlanconfig/ignores interface names given to wlanconfig https://bugs.launchpad.net/bugs/182988 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 297254] Re: OEM reset all my customization
oem-config doesn't do the kind of customization you are talking about, and it's not designed to. Customizing the desktop The Right Way (tm) is much more difficult than one might expect because the configuration options are kept in a host of different places. The GNOME desktop specification is not particularly sensitive to branding issues, and what branding specs there are, GNOME developers pretty much ignore. If you are seeking to use the same configuration for many computers, it is advisable to create a .deb package that does the work simply by installing the package. (That's the way we handle it at the IYCC Distribution. http://archive.iycc.net/iycc. See in particular the iycc- desktop, iycc-halucinar, and iycc-cuadrado-gnome-desktop packages.) You will need to be patient, though, because it's hard to round up where everything is. However, if you are "customizing" for a particular customer, then look here for a procedure I wrote that will accomplish what you want: https://bugs.launchpad.net/ubuntu/+source/oem- config/+bug/153310/comments/3. I suggest that this "bug" be converted to a question or be relegated to "Wishlist" status. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- OEM reset all my customization https://bugs.launchpad.net/bugs/297254 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
>Bug 306672 is about update-manager grabbing focus too often, By the >looks of this bug it doesn't grab focus unless told to? Not correct. Update-manager grabs focus inappropriately, and it needs to be fixed. Update-manager steals focus whenever it creates a window. The fix is to change the focus_on_map setting to "false", as I have described. In some circumstances, update-manager sends requests to gkdebconf and other debconf frontends, which ALSO steal focus. I've described the fix in a prior post. Gkdebconf and the debconf frontends are written in different languages, so the syntax is different, but they share the same solution: Tell those programs not to grab focus when it creates the window. To my knowledge, separate bugs have not been created for gkdebconf and debconf to fix their problems, but I leave that to the "developers responsible" that (according to some) are "already aware". I don't want to be "uncool," even if I am just a hapless gringo in a Texas border town. ;-) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
> So could you provide a patch so others can test? Somebody else will have to run with the ball on that. -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
[banging head on desk] Update-manager doesn't get focus randomly. It has to ask for it. The window manager (metacity) just does what it's told to do. Anything the window manager does to prevent focus-stealing is a sub-optimal solution, but it's a necessary one when applications are written egocentrically. (By this, I'm not talking about the developer's mental health issues: we're all egocentric. An egocentric application means an application written as if the application is either the only application running or the most important application to the user at the time) "Obviously, it's not a small, simple fix." Contrary to Sarah's assertion, setting "focus_on_map" to "false" in every instance it appears in update-manager *fixes* update-manager: Update-manager ceases to steal focus when that's done. Here are the files affected: ./data/glade/UpdateManager.glade ./AutoUpgradeTester/DistUpgrade/DistUpgrade.glade ./DistUpgrade/DistUpgrade.glade ./debian/update-manager/usr/share/update-manager/glade/UpdateManager.glade ./debian/update-manager/usr/share/update-manager/glade/DistUpgrade.glade ./debian/tmp/usr/share/update-manager/glade/UpdateManager.glade ./debian/tmp/usr/share/update-manager/glade/DistUpgrade.glade Unfortunately, it doesn't fix gkdebconf or debconf's frontends, which ALSO have the same bug. Here's how to fix those: gkdebconf (I'm using version 1.2.64ubuntu1 to test): Insert the following line 101 in ./src/interface.c: gtk_window_set_focus_on_map (GTK_WINDOW(win), FALSE); and recompile. debconf (I'm using version 1.5.20): Insert the following line 70 to /usr/share/perl5/Debconf/FrontEnd/Gnome.pm: $this->win->set_focus_on_map(0); Fixing the other frontends (e.g., KDE) are left as an exercise. Caveat: The changes to update-manager described above need to be fine tuned. It's a Good Thing (tm) to allow the GtkWindow to get focus when the user fires up Update-Manager the first time. I just didn't have the patience to figure where in the code that is. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154277] Re: cups serial backend failed with Permission denied
I can tolerate the "fix" as a stopgap, but alarms are going off in my head that it's a bad idea. ("Danger Will Robinson! Danger Will Robinson!") Giving the serial backend root privileges by default seems the *wrong* approach to me. I'm having a hard time accepting that the only way to solve this problem is to allow yet another process to run with root privileges. (BTW -- This bug seems to be related to http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=489975. ) CUPS seems to be a Lernaen Hydra when it comes to getting permissions right. Martin. more than anyone, has been working on cups permissions for a while now, and he's expressed frustration, too. I can understand why he and others might want to give the process root privileges and cross this bug off the list. Yes, we can give EVERY process root privileges and that would make many things easier, but doing so will undo decades of work ensuring *nix systems stay secure. It will also be asking for trouble later. There is (almost) always a way to "get 'er done" without escalating privileges. Theoretically, administering the printing system should be done by the lpadmin group and the actual printing should be done by the lp group. (At many (most?) sites, it makes sense to give lpadmin rights to most users, but in business / enterprise settings, that's NOT the right thing.) If lp or lpadmin need to print to the serial port, It should be possible to make them members of the dialout group and get it to work. >Already tried to put the user lp (owner of serial backend process) into group dialout - with no success. My reaction is similar to Martin's here: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=462149#29. If the user writing to /dev/ttyS0 is a member of the dialout group, that user has enough permission. Another user besides lp must be doing the work. I note Anthony Gelberg's comments: "This led me to suspect permissions, and sure enough, changing /dev/ttyS0 to 0666 worked. I didn't really understand this, as root had rw permissions anyway. I had a glance at scheduler/cups-deviced.c, and there is certainly some magic there relating to the user that it runs the backend as. Unfortunately, I don't have time to delve deeper, but see comments around line 204. " See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489975 Neither do I have the time to figure it out (even if I understood the code), but wag-and-a-poke debugging might do the trick. Before escalating the serial backend to root, the following solutions should be tested, in the listed order (maybe they have, but that should be documented somewhere): 1. adding the lp group to the dialout group, 2. adding the lpadmin group to the dialout group. 3. adding the lpadmin user to the dialout group. (I don't have a serial printer handy, so I can't do it.) I'm sensitive to the importance and complexity of getting printers configured and of setting device permissions work properly on a *nix system. A couple of years ago, I wrote to a colleague about my frustrations at how hard it was to set up a printer. https://lists .linux-foundation.org/pipermail/printing-summit/2006/000451.html. The ease of printing has come a long way in the three years since I first tried to set up a Unix printer, and that's a Good Thing (tm). We don't want to throw out the baby with the bathwater, however. I know that (eventually) AppArmor, SELinux, and related solutions will provide additional security to the system, but such top-down security measures are no substitute for setting permissions properly at the device, process, and file levels. (I know, "devices are files." ) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- cups serial backend failed with Permission denied https://bugs.launchpad.net/bugs/154277 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 303545] Re: oem-config should also set the host name
> I'm not an OEM... I'm an administrator trying to integrate Ubuntu oem-config is probably not the best solution for you. Try the system-imager* packages instead. >Contrary to your statement changing the hostname IS a > simple matter Try this. . . . Assume a user name of "penguin", the first host name is "oldname", and the name you want is "newname". Set up the machine with "oldname" as the host name. Change the host name to "newname". Reboot. Then execute the following commands: # rgrep oldname /etc >> /home/penguin/newname.log # find /dev | grep oldname >> /home/penguin/newname.log # rgrep oldname /boot >> /home/penguin/newname.log # rgrep oldname /var >> /home/penguin/newname.log # rgrep oldname /usr/share/ >> /home/penguin/newname.log Then open /home/penguin/newname.log. If the file is empty, you found everything. If it's not, you overlooked something. >On the other > hand, imaging like hardware is so insanely common that it makes sense to > offer the capability. We have found imaging to be a suboptimal solution in a manufacturing environment, for a variety of reasons. It's cheaper, faster, and more reliable to use oem-config. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas -- oem-config should also set the host name https://bugs.launchpad.net/bugs/303545 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
> Please don't assign to ubuntu-core-dev, really. I meant to. Really. > It sends a mail to all >core-devs (including those who don't work on update-manager...). That's a Good Thing (tm). I knew what I was doing and what the effects would be. > There is no need to take any further action in > order to notify the appropriate people, The process must be broken, because this bug is two years old and hasn't been assigned. The bug severity hasn't even been set (which, IMHO, should be HIGH). BTW, the problem isn't metacity. The problem is that update-manager should not ask for focus in the first place. This is a problem that has been solved over and over again in other applications. >the developers responsible for >this component are already aware of it by virtue of being bug contacts for >this package in Launchpad. That so? H. . . . .So which of said "developers responsible" have any idea how to turn off focus-stealing? If assigning the bug to ubuntu-core-dev is a Bad Thing (tm), perhaps there should be a way to flag ubuntu-core-dev as a Wrong Person (tm) and tell ubuntu_update-manager.assignee that the Wrong Person (tm) cannot be a ValidAssignee. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
Daniel, unless you know of someone else to fix this, the maintainer of the package is the right person. In this case, the maintainer is ubuntu- core-dev. Sebastien. Two solutions: 1. Remove every reference to grab_focus from: ./UpdateManager/Common/SimpleGladeApp.py, (I show lines 239 through 245) and ./UpdateManager/UpdateManager.py (I show lines 347 and 348) See http://library.gnome.org/devel/pygtk/2.10/class-gtkwidget.html #method-gtkwidget--grab-focus 2. If that seems too draconian, in ./DistUpgrade/DistUpgrade.glade set: False See http://www.pygtk.org/docs/pygtk/class-gdkwindow.html#method- gdkwindow--set-focus-on-map Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Changed in: update-manager (Ubuntu) Assignee: (unassigned) => Ubuntu Core Development Team (ubuntu-core-dev) -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
This bug needs to be raised in importance and fixed. It hoses up systems, is easy to correct, and has been languishing for two years. ** Changed in: update-manager (Ubuntu) Assignee: (unassigned) => Ubuntu Core Development Team (ubuntu-core-dev) -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 35876] Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus
This problem still exists in Hardy. Because of it, a kernel update got hosed up. I fired off update-manager and switched to working on something else. While I was typing, a window popped up asking whether I wanted to change /boot/grub/menu.lst. The timing was such that I hit the spacebar just when the window popped up, so the window instantly disappeared, the updated kernel was installed, but the grub menu doesn't have an item for the new kernel. Without intervention on my part, this machine would end up keeping the old kernel until the next time the kernel was updated. Fortunately, I know what happened and I know how to update the grub menu. However, my customers don't know about what's happening under the hood, and they shouldn't have to. I'm astounded at how long this has been a problem. As mentioned by others, this should be a trivial fix. WTF? Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Changed in: update-manager (Ubuntu) Status: New => Confirmed -- 'Downloading package information' and 'building dependency tree' progress dialogs steal focus https://bugs.launchpad.net/bugs/35876 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 303545] [NEW] oem-config should also set the host name
This is not as good an idea as it seems, because changing the host name (without breaking your system) is not a simple matter. There are a number of programs that hard-code the host name. A partial list: apache postfix procmail dwww ssh # keys would need regenerating, too motd host The nature of oem-config is that the OEM customizes the installation. That means there is not a way to know ex ante what software is installed and consequently not a way to know what to change or how. Further, LVM maps logical volume device names based on the hostname, and it's not a trivial matter to change the names if you don't know how the system is partitioned. If the OEM wants to allow the customer to change the hostname, the OEM should write a custom script to do that. FWIW, we at IYCC set the hostname during the initial installation. I've never had a customer who particularly cared what the hostname was. It WOULD make sense for the various programs NOT to hardcode the hostname but instead use a system variable. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- -- oem-config should also set the host name https://bugs.launchpad.net/bugs/303545 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 297262] Re: OEM, on a normal Ubuntu installation, preserve the first user password for sudo
Colin is right; OEM wasn't designed for the use case stated, so you may have unpredictable results. However, I've been able to pull the rabbit out of the hat, at least for an earlier incantation of oem-config. Here's what I did: 1. Reboot the machine. 2. At the GRUB menu, select the recovery mode. 3. When you get to the "friendly recovery" menu, drop to root shell. 4. As root, delete the regular user on the box. E.g., if you set up yourself with a username of "foo": # deluser --remove-all-files foo // This would be a good time to get some coffee, smoke a cigarette, check your email, // or go to the bathroom. 5. Add the oem user: # adduser oem For the "Full Name", you can put what you like or nothing at all, but "OEM" or your company name are common choices. 6. Give permissions (if someone knows of a more elegant way of doing this from the command line, I'd appreciate hearing about it): # adduser oem admin # adduser oem adm # adduser oem dialout # adduser oem cdrom # adduser oem floppy # adduser oem audio # adduser oem dip # adduser oem video # adduser oem plugdev # adduser oem fuse # adduser oem lpadmin 7. Install oem-config. (In the following, oem-config-gtk installs the GNOME GUI, which isn't strictly speaking necessary but which many folks seem to prefer over the command line.) # aptitude install oem-config oem-config-gtk 8. Reboot # reboot now Bada-bing-bada-boom. Your machine should now boot into an OEM configuration. As I said, the foregoing procedure worked for me on a prior version of oem-config. Your mileage may vary because Colin is continually tinkering with oem-config in his heroic, thankless, and unending struggle to herd cats (a/k/a system builders and manufacturers). For more specifics on his efforts to keep us all happy, see http://www.youtube.com/watch?v=Pk7yqlTMvp8 Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- OEM, on a normal Ubuntu installation, preserve the first user password for sudo https://bugs.launchpad.net/bugs/297262 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 99489] Re: avahi-autoipd gives me an useless default route
At IYCC, we've seen this problem over and over again, both on IYCC computers and on Ubuntu computers of our customers . We've concluded that avahi is a broken implementation of a bad idea, and the only thing that seems to work reliably is to get it off the machine. Here's the best solution: # aptitude purge avahi-autoipd avahi-daemon avahi-utils libnss-mdns # aptitude install ifmetric Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net On Sat, Nov 15, 2008 at 5:13 PM, Alecz20 <[EMAIL PROTECTED]> wrote: > avahi-autoipd gives me an IP address which overrides the settings in > Network manager. This mean that after each reboot I have no valid > network connection. I have to restart the network or re-configure > Network manager each time. -- avahi-autoipd gives me an useless default route https://bugs.launchpad.net/bugs/99489 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 148454] Re: console-kit-deamon spawns too many threads
@IronStorm >everything on the desktop >depends on it for something Yet another example of rampant dependency inflation. I've complained about this before in a variety of contexts. Somehow, the entire open source developer community needs to get a handle on it. It's a big problem for IYCC, and I suspect other OEMs, when trying to tailor a machine for a particular use case or market. The Debian Policy Manual has a a very good statement on how to categorize dependencies. http://www.debian.org/doc/debian-policy/ch-relationships.html Unfortunately, the policy seems not to be enforced nearly enough. In particular, the entire community should make greater use of Suggests, Enhances, and Recommends dependencies, of virtual packages that "Provide" packages, and of meta-packages that are similarly careful about dependency relationships. Dependency inflation isn't restricted to Ubuntu. Best I can tell, all the distros are guilty of it, including RedHat. :-) We're working on weeding it out of the IYCC Distribution, but it's not a trivial task because of the pervasiveness of the problem. I'm not sure how to create a process that would herd the cats, but it's what's needed. Perhaps each distro should have a Dependency Czar to review dependencies and crackdown on ever-expanding dependencies. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 281720] Re: Lack of terminals in ubuntu 8.10
*** This bug is a duplicate of bug 129910 *** https://bugs.launchpad.net/bugs/129910 I'm not sure what is gained by arguing about version and bug numbering, but since I've been quoted, I'll take the bait and dive in. I did NOT say that the bug was Gutsy "only". I did say that it WAS a bug in Gutsy, and continues to be a bug, in response to someone unilaterally setting the bug to WILL NOT FIX. It's been a regression on every version since Gutsy, and it still should be fixed. The "fix" in Hardy was a crude hack that has made my job more difficult, but at least we can get a framebuffer working outside X. Amazingly, Intrepid breaks the console once again, albeit in a different way. In fairness, Intrepid's new uvesafb / v86d approach has the potential to _actually_ fix the console someday, but our in-house testing shows it to be beta quality at this time. (I'm not sold on the conceptual model of v86d, but I've still got an open mind.) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Lack of terminals in ubuntu 8.10 https://bugs.launchpad.net/bugs/281720 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 111061] Re: Wine use Windows colors instead of Ubuntu colors
It's good to learn from others' mistakes. :-) Okay, so why don't we start by creating a Default.theme (using the default wine Window-ish colors) and Human.theme that is in the same format as the reg files, and have wineconf read that? If memory serves correctly, the settings are saved to ~/.wine/user.reg. A separate package with the themes ("wine-themes"?) seems prudent as it would modularize the implementation better, IMHO. Other desktops can submit themes to the theming package, or create their own packages based on wine-themes (e.g., "wine-themes-ubuntu-studio", "wine-themes-iycc", etc.). Endolith, can you use that script of yours to scrape the gnome settings from gconf, gtkrc, and perhaps other obvious places and save a .theme file, at least as a "wag and a poke" themer? BTW, seems like it would be pretty simple to create a Wine Color Chooser similar to Gnome Color Chooser that creates the Wine theme file. Maybe we could even add a checkbox to Gnome Color Chooser to make the wine theme. But writing a new program we should probably leave to another day. :-) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas [EMAIL PROTECTED] 956.857.1172 -- Wine use Windows colors instead of Ubuntu colors https://bugs.launchpad.net/bugs/111061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 111061] Re: Wine use Windows colors instead of Ubuntu colors
@Scott Is that already implemented? Is the syntax of .theme documented anywhere? Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Wine use Windows colors instead of Ubuntu colors https://bugs.launchpad.net/bugs/111061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 111061] Re: Wine use Windows colors instead of Ubuntu colors
Here's a pretty good description of the current state of things: http://live.gnome.org/GnomeArt/Tutorials/GtkThemes. From that article: Everything you want to change is being changed in so called "styles". Within these styles you have two kinds of properties. On the one hand there is a limited set of predefined style-properties of the GTK+ theming system, which define things like the width of the scrollbar. On the other hand there are the theming possibilities the engines define. These engine styles are, where most of the theming options are possible. The interesting part about the GTK theming system is that different styles are merged to create the final one. So what you usually will do is to define a base style with all common options in it, and then change colors for a specific widget. It would be possible to code around each theme engine, at least if we have a list of them, but that would require more patience than I have. Perhaps the Right Way to Do It (tm) would be to standardize the color settings for GTK. Another option would be to scrape a couple or three of the most common engines and grab the rest from gconf. This leads me back to the conclusion I came to a while back: the solution should be done as a separate project and not as part of the WINE package. If done in a standardized way, the project could be useful in contexts other than WINE. Loye -- Wine use Windows colors instead of Ubuntu colors https://bugs.launchpad.net/bugs/111061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 111061] Re: Wine use Windows colors instead of Ubuntu colors
>Hmm.. I should be reading the colors from gconf instead of directly from >gtk? I noticed that some colors were in gconf, but I thought the >location varied with the gtk engine you are using. You might be right. The way that ubuntu/gnome/gtk handle branding and theming pretty much sucks, so I do feel your pain. We've had to wade through a lot of undocumented packages to get it right. Even so, my guess is that gconf is the missing piece of the puzzle you are looking for. We at IYCC use gconf for our branding, and it works. Take a look at the first six screenshots here: http://www.iycc.net/screenshots. You, however, have a slightly different problem because you are working the other direction, i.e., you are trying to follow the settings, not overwrite them. >What's the name of the KDE tool? wineconfig. Yuriy, one of the posters in this thread, is the author. I actually took a stab at this project in the past, but decided that the problem should be fixed in separate package, the way Yuriy did it. I documented my reasoning, so take a look at the earlier postings in the thread. -- Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Wine use Windows colors instead of Ubuntu colors https://bugs.launchpad.net/bugs/111061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 111061] Re: Wine use Windows colors instead of Ubuntu colors
Endolith, We've been learning a thing or three about the subject lately, and here's what we've found. /usr/share/gconf/defaults/ is where the original defaults come from. It gets copied to the users' home directories when the users log in the first time. The gnome-color-chooser application creates a separate file which overrides the particular user's default settings. Making some changes with gnome-color-chooser and then reading the resulting file should be instructive on finding which key/variable pairs you need to read. The gconf-editor package is a graphical interface to gconf, and it may also be of assistance. python-gconf contains the bindings that allow you to work with gconf in python. (KDE's wine configuration tool is written in python, if my memory serves me correctly. ) Happy trails, Loye Young On Fri, Aug 1, 2008 at 9:37 PM, Endolith <[EMAIL PROTECTED]> wrote: > I tried to write a script to update the colors based on Gnome, but I > give up. I can't figure out how to read them from various places, or > when I do read them, they don't match the actual colors. It works > somewhat for some themes. See > http://ubuntuforums.org/showthread.php?p=5506889#post5506889 > > -- > Wine use Windows colors instead of Ubuntu colors > https://bugs.launchpad.net/bugs/111061 > You received this bug notification because you are a member of Ubuntu > Wine Team, which is a bug assignee. > -- Loye Young Isaac & Young Computer Company Laredo, Texas [EMAIL PROTECTED] 956.857.1172 -- Wine use Windows colors instead of Ubuntu colors https://bugs.launchpad.net/bugs/111061 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 283861] Re: Wrong time zone defaults for some countries
> Loye, it sounds like you're suggesting that Spain not be the default > country for Spanish. That's a subtly different bug than this one -- > that once we think the user is in Spain, we set the default time zone to > New York. Perhaps I didn't clearly make the connection between the report and my comments. >From the bug report: >If you enter Catala or Espanol as your language (for example), your >country is marked as "ES" (so far so good). However, when you get to >the timezone page, your default timezone is New York! 1. The reporter suggests that language is a good basis for inferring country and concomitantly tzsetup/country/CC. I disagree. In the particular case of Espaรฑol, for example, the default country _should_not_be_ Spain, but rather Mexico, and the timezone should be either Central or Eastern (depending on your preference for modal or least squares default selection). 2. I agree, however, that the selection of timezones needs a revamping because the way we do it now will get the answer wrong more often than right. My suggestion is to change the way we select timezones altogether. Happy Trails, Loye Young -- Wrong time zone defaults for some countries https://bugs.launchpad.net/bugs/283861 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 283861] [NEW] Wrong time zone defaults for some countries
The suggestion of coming up with a better way to select the time zone is a good one, and the case of "Espaรฑol" is a good example of the complications involved. I agree we need a better way. However, the fix suggested would be a worse solution than the current default. New York is a BETTER selection than any European time zone. In the United States alone, 34 million speak Spanish at home, which is roughly comparable to the number of native Spanish speakers in Spain itself. Most Spanish speakers are in Latin America; of all countries with majority Spanish speakers, only Spain is outside of the Americas. Mexico has the most native Spanish speakers of any country, including Spain. If you want to make a reasonable default, Central Time (aka Chicago) has the most Spanish speaking people. A Least Squares regression to take into account the Spanish speaking population around the world, New York turns out to be the right choice. (While it's not the zone with the greatest number, it is "least wrong" on the whole. ) Most of IYCC's customers are native Spanish speakers, born and raised in Texas, in the Central time zone. Few of them know to select "Chicago" as their time zone. How are folks in south Texas supposed to know to pick Chicago as the correct time zone, when Texas is the second most populous state in the United States. (Texas has twice the number of inhabitants as the entire state of Illinois, where Chicago is located.) To complicate matters more, several parts of the Central timezone have their own rules. The state of Indiana has a few locations that have in the past opted out of Daylight Savings Time, so there are separate rules for them. The hapless Spanish speaking Texans have no way of knowing which of the little dots on the map they are supposed to click, and it's difficult to select the one you want when you do. Perhaps a better solution would be to simply ask the user to type the country, state or province, and city (or perhaps postal code) and have the system prompt with a reasonable choice. There are many widely databases that have location information, and there's just no reason to require the user to figure it out. Besides, the location information could and should be used for populating, inter alia, the "About Me" address fields and the OpenOffice.org User Data infomation. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Wrong time zone defaults for some countries https://bugs.launchpad.net/bugs/283861 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 274048] Re: package/commands oem-config-* do not contain manpages and documentation
I'm in whole-hearted agreement with any effort to document and provide a manual page for every package in the repository, and in particular, for oem-config in particular. However, I'm not sure the reason for the two attachments sjolle uploaded. The packages in the "Dependencies.txt" file SHOULD NOT be the dependencies of oem-config, because it would break any OEM configuration that wasn't the same as listed. Inasmuch as the whole point of the oem- config package is to enable custom configurations, the dependency list should be kept to an absolute minimum necessary for the oem-config package to run successfully. The "OemConfigLog.gz" file seems not to have relevance to documentation at all. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net/cuadrado-system "Check out the IYCC repository at http://archive.iycc.net/."; -- package/commands oem-config-* do not contain manpages and documentation https://bugs.launchpad.net/bugs/274048 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 89364] Re: Apache2 default site contains only the words "It works!"
There must be some middle ground. Perhaps something like: IT WORKS! This is the default web page for this server. The fact that you see this page means that the host computer is booted up, the web server software is running, and the networking between your computer and the host computer is functioning properly. If this page is not what you expected, there are many possible causes. Check with the owner or administrator of the server for more information. -- Apache2 default site contains only the words "It works!" https://bugs.launchpad.net/bugs/89364 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153727] Re: Ethernet device's number increases by one after every reboot
IMHO, this should be marked as HIGH priority. This bug breaks the networking for many machines, and few lay persons (or even geeks) would be able to figure out what happened. It's a deal- stopper for us OEMs, and many regular people, too. What we're having to do at IYCC is rewrite several packages to work around the problem. This one problem is soaking up more developer time than all others combined. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Changed in: debian Status: New => Confirmed -- Ethernet device's number increases by one after every reboot https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153727] Re: Ethernet device's number increases by one after every reboot
The status of "won't fix" relates to the udev package, not to the issue as a whole. As mentioned above, the problem is not the udev package; it's the kernel driver that receives the MAC address from the network interface. Consequently, "won't fix" is the correct status for the udev package. With respect to testing with the linux-image-2.6.27-* package, we have tested by installing the package with Hardy. Unfortunately, however, that kernel breaks the video driver and the framebuffer in a manner that makes the machine unusable, so we are unable to verify whether the linux-image-2.6.27-* kernel package fixes this bug. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Ethernet device's number increases by one after every reboot https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 237300] Re: main window disappears from the Window list
Per reporter, fix released ** Changed in: wine (Ubuntu) Status: New => Fix Released -- main window disappears from the Window list https://bugs.launchpad.net/bugs/237300 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 237300] Re: main window disappears from the Window list
Per reporter, fix has been released. ** Changed in: pq (Ubuntu) Status: Confirmed => Fix Released -- main window disappears from the Window list https://bugs.launchpad.net/bugs/237300 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153727] Re: Ethernet device's number increases by one after every reboot
Scott James Remnant is correct: "The kernel need not pick a *RANDOM* MAC address, it could use one that's at least predictable" This is an old problem that has bee solved. The Network Working Group documented the issue in 1998 and provided the correct solution: reverse the bit order of the LAN adapter to restore it to canonical form. See RFC 2469, http://tools.ietf.org/html/rfc2469. If the kernel reads an apparently invalid MAC address, it should first try reversing the bit-order. If the reversed-bit-order is a canonically valid address, use the so-reversed MAC, per RFC 2469. There is the remote possibility that reversing the bit order would not yield a canonically correct address. Consequently, if both the reported address and the reverse-bit-order address are *both* invalid, replace the Organizationally Unique Identifier of original MAC with a predetermined, specified OUI or Individual Address Block (IAB). (See http://standards.ieee.org/regauth/faqs.html). Ideally, the IEEE would assign a specific OUI or IAB for use by the Internet community in such cases. (It's not all that expensive and requests are processed within 7 days.) Such an approach would reuse the device-specific numbering already assigned by the vendor to the interface, and would likely result in fewer duplicates on the same LAN (although it would still be statistically possible). Here's a summary of the logic I propose: read address reported by hardware is address valid? If yes, set MAC equal to address as reported. If no, set MAC (1) = reverse bit order of address reported is MAC (1) valid? if Yes, set MAC = MAC (1) if No, replace OUI of MAC with specific, predetermined OUI, and set MAC to the new value. exit Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Ethernet device's number increases by one after every reboot https://bugs.launchpad.net/bugs/153727 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 251056] Re: OEM Install does not seem to like user to be named "oem" again
@ Colin >>Would you like me to fix this bug or bug 153311? There's no reason to choose between them because we can have our cake and eat it too. If the new username is to be "oem", don't delete the oem user at all. Instead, simply delete and recreate the home directory for oem. -- OEM Install does not seem to like user to be named "oem" again https://bugs.launchpad.net/bugs/251056 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 227881] Re: tftpd-hpa does not use /etc/default/tftp-hpa options
There are some reasonable tradeoffs between using inet and running standalone, and it's possible to run tftpd-hpa in either mode. Which one is better depends on the use case, so we should preserve the ability to choose. However, I also usually use standalone (i.e. not inet), and I agree that the whole thing, including the defaults, should be rethought and streamlined. >>attempts to purge it would remove tftpd-hpa The problem here isn't the package or the dependencies (which are correctly stated); it's the package manager. Apt-get and the graphical managers often don't "Do the Right Thing" (tm). Instead, use aptitude for package management. It almost always gets the answers right, and when there are alternative solutions, it presents choices for the system admin. If you need very fine-grained control, aptitude's full-screen mode is unbelievably powerful, and allows you to play minesweeper on just about any computer in the world. :-) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- tftpd-hpa does not use /etc/default/tftp-hpa options https://bugs.launchpad.net/bugs/227881 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 24626] Re: Too many repositories "dynamic mmap ran out of room"
If you are still having trouble after raising the cache limit, try one or both of the following: 1) Clean the package cache, viz: # aptitude clean 2) Clean up your repository list: 2.1) Ensure that your repository lists in /etc/apt/sources.list refer to not more than one release (i.e., one of dapper, edgy, feisty, gutsy, hardy, etc.). 2.2) Ensure that your repository lists in /etc/apt/sources.list refer to a limited number of full repositories. Don't include several mirrors of the same repository, and don't include competing repositories (i.e., ubuntu OR debian OR mepis, etc., but not more than one). 2.3) update your package lists, viz: # aptitude update 3) As always, report back whether these suggestions helped, so that others can benefit. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- Too many repositories "dynamic mmap ran out of room" https://bugs.launchpad.net/bugs/24626 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 153001] Re: Characters are rendering weirdly, across applications
Haven't seen this issue lately. Must have gotten fixed along the way. OK to mark as fixed. On Sat, Aug 2, 2008 at 4:53 PM, Jean-Baptiste Lallement < [EMAIL PROTECTED]> wrote: > Thank you for taking the time to report this bug and helping to make > Ubuntu better. You reported this bug a while ago and there hasn't been > any activity in it recently. We were wondering is this still an issue > for you? Can you try with latest Ubuntu release? Thanks in advance. > > ** Changed in: ubuntu > Status: New => Incomplete > > -- > Characters are rendering weirdly, across applications > https://bugs.launchpad.net/bugs/153001 > You received this bug notification because you are a direct subscriber > of the bug. > -- Loye Young Isaac & Young Computer Company Laredo, Texas (956) 857-1172 [EMAIL PROTECTED] -- Characters are rendering weirdly, across applications https://bugs.launchpad.net/bugs/153001 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 247746] Re: winbind should be downgraded to "Recommends"
Scott, Is this going to be backported to Hardy? Hardy is a long term support release, and this is an easy fix, so it makes sense to do. Loye -- winbind should be downgraded to "Recommends" https://bugs.launchpad.net/bugs/247746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 195140] Re: SetHostName can be called by users
We no longer have a dog (or a lemur) in this race because we are now avahi-free. IYCC made a company-wide decision to prohibit avahi-daemon (including zeroconf, etc.), avahi-autoipd, mdns, network-manager, and dhcdbd on our network or in our products. (We ended up having to build a fork of Ubuntu to make everything work.) Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- SetHostName can be called by users https://bugs.launchpad.net/bugs/195140 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251056] Re: OEM Install does not seem to like user to be named "oem" again
Change committed enshrines the bug instead of fixing it. ** Changed in: oem-config (Ubuntu) Status: Fix Committed => In Progress -- OEM Install does not seem to like user to be named "oem" again https://bugs.launchpad.net/bugs/251056 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 251056] Re: OEM Install does not seem to like user to be named "oem" again
I don't understand the rationale for this. Using oem as a user name SHOULD work, as the bug reporter expected. The fact that oem as a user doesn't work like it did before is a recent regression. Disallowing completely the oem user name makes the problem WORSE. We should return to the former behavior that allowed iterative use of oem-config simply by using the oem user name. The technique provides great flexibility and efficiency by enabling the system builder to test and refine the set up for the customer, without having to reinstall and reconfigure the entire system. The use oem-config is a dollars-and-cents issue for us because the margins on hardware sales are so thin. Oem-config's utility is directly tied to the labor cost savings it provides in customizing systems. If we cannot iteratively test the system setup after configuration but before shipment, the labor savings are lost. Note: Simply rebooting into oem before executing oem-config-prepare is no substitute. We've often found that the initial user's setup after firing off oem-config-prepare was not as expected. By running oem-config iteratively, we've been able to trap mistakes in configuration and keep product quality high. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- OEM Install does not seem to like user to be named "oem" again https://bugs.launchpad.net/bugs/251056 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210779] Re: oem-config isn't removed after completion
See also Bug 251056. -- oem-config isn't removed after completion https://bugs.launchpad.net/bugs/210779 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251056] Re: OEM Install does not seem to like user to be named "oem" again
IYCC confirms that this bug exists. It causes problems with our installation and testing procedures. See also Bug 210779. ** Changed in: oem-config (Ubuntu) Status: New => Confirmed -- OEM Install does not seem to like user to be named "oem" again https://bugs.launchpad.net/bugs/251056 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 247746] [NEW] winbind should be downgraded to "Recommends"
Public bug reported: Binary package hint: wine Wine now depends on winbind, but the dependency should be downgraded to "Recommends". In many (maybe most?) instances, having winbind installed alongside Wine is good, right, just, and builds a better tomorrow. However, the system administrator may not want to have Linux machines connecting to his legacy Windows machines. Because winbind is not essential to running other applications on Wine, there is no reason to require winbind in each and every case. A Recommends dependency gives the best of both worlds: winbind is installed by default, but the admin may remove it without breaking Wine itself. Happy Trails Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Affects: wine (Ubuntu) Importance: Undecided Status: New -- winbind should be downgraded to "Recommends" https://bugs.launchpad.net/bugs/247746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 244299] [NEW] create a link to x-sudo
Public bug reported: gksu, gnome-sudo, and kdesudo are all packages that provide the same functionality: they provide a graphical interface to sudo that allows the user to gain root privileges. Which one depends on the default desktop environment, but from the standpoint of the program that needs root privileges, they are fungible. However, most GUI programs guess, hardcode, or depend upon a particular sudo GUI. Sometimes they get the answer wrong, which causes needless breakage and aggravation. The various graphical interfaces to sudo should create a link to x-sudo in the /etc/alternatives directory. Then, other GUI programs can simply point to x-sudo instead of trying to [guess | parse | hardlink] which desktop environment happens to be in charge at the moment. Such a solution would also help OEMs who want to give their customers a choice in desktop environments but also install various desktop-agnostic configuration scripts or programs. In particular, oem-config would be able to point to x-sudo irrespective of whether GNOME, KDE3, KDE4, XFCE, fluxbox, or a private label desktop environment is installed. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Affects: gksu (Ubuntu) Importance: Undecided Status: New ** Affects: kdesudo (Ubuntu) Importance: Undecided Status: New ** Affects: kdesudo-kde4 (Ubuntu) Importance: Undecided Status: New ** Affects: oem-config (Ubuntu) Importance: Undecided Status: New ** Also affects: kdesudo (Ubuntu) Importance: Undecided Status: New ** Also affects: kdesudo-kde4 (Ubuntu) Importance: Undecided Status: New ** Also affects: oem-config (Ubuntu) Importance: Undecided Status: New -- create a link to x-sudo https://bugs.launchpad.net/bugs/244299 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 244299] Re: create a link to x-sudo
ssh-askpass is a different animal from sudo and should not be linked to this bug report. Mea culpa. ** Changed in: ssh-askpass (Ubuntu) Status: New => Invalid -- create a link to x-sudo https://bugs.launchpad.net/bugs/244299 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 244299] Re: create a link to x-sudo
** Also affects: ssh-askpass (Ubuntu) Importance: Undecided Status: New -- create a link to x-sudo https://bugs.launchpad.net/bugs/244299 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 224305] Re: oem-config thinks kde is gnome
On Mon, Jun 30, 2008 at 8:45 AM, Colin Watson <[EMAIL PROTECTED]> wrote: > Checking is harder than you might hope. > > The problem (as reported anyway) isn't really the desktop; the problem is simply that oem-config-prepare is looking for gksudo to gain root privileges, when kdesudo is installed. A more general and stable solution is the following: 1. in oem-config-frontend, create an x-sudo entry using update-alternatives, ; 2. in oem-config-gtk and oem-config-kde, link gksudo or kdesudo (as the case may be) to x-sudo; and 3. change oem-config to point to x-sudo instead of trying to figure out which desktop is installed. Come to think of it, an even better and general solution would for gksu and kdesudo to maintain a link to x-sudo. I'll file a bug-report. Loye -- Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Attachment added: "unnamed" http://launchpadlibrarian.net/15691700/unnamed -- oem-config thinks kde is gnome https://bugs.launchpad.net/bugs/224305 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 99489] Re: avahi-autoipd gives me an useless default route
>he avahi default route has a very high metric set, this route will only >ever be used by the kernel when there are no other routes available. That's not the behavior we're seeing on Hardy fresh installs. According to RFC 1122, multiple default routes *must* be supported, but in practice that's honored more in the breach than in the observance. (In fairness, the avahi protocol at least tries to implement some adherence; many networking implementations don't. ) I stand by my contention that a "default" route is nonsensical for link-local interfaces, but perhaps a more robust solution to the multiple default routes issue is in order. -- Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net ** Attachment added: "unnamed" http://launchpadlibrarian.net/15570908/unnamed -- avahi-autoipd gives me an useless default route https://bugs.launchpad.net/bugs/99489 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 99489] Re: avahi-autoipd gives me an useless default route
Steve is right. Setting up a default route on a link-local interface is inherently flawed. The default route is the the "gateway of last resort", i.e., the router address used when no other known route exists for a given IP packet's destination address. However, the basic architectural assumption of link-local networks is that no routable address is configured. Thus, by definition, no routers or dhcp servers are available to the interface. Consequently, it makes no sense for avahi-autoipd to assign a default route. Worse, when the host has multiple interfaces, avahi interferes with standards-compliant network connections to the internet. (For example, the host has both a wired NIC connected to routeable network and a wireless card either not connected or connected only to a local printer.) Avahi-autoipd's assignment of a default route will result in multiple default routes (one from it and one from the actual router), causing connectivity to the internet to break. See, e.g., http://ubuntuforums.org/showthread.php?p=4501456 (noting that the best solution is to purge avahi and its cousins). Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.net -- avahi-autoipd gives me an useless default route https://bugs.launchpad.net/bugs/99489 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192258] Re: avahi should be downgraded to Recommends:
As we say here in Texas, Yee Hah! -- Loye Young Isaac & Young Computer Company Laredo, Texas ** Attachment added: "unnamed" http://launchpadlibrarian.net/15413207/unnamed -- avahi should be downgraded to Recommends: https://bugs.launchpad.net/bugs/192258 You received this bug notification because you are a member of Kubuntu Team, which is subscribed to kubuntu-meta in ubuntu. -- kubuntu-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 172367] Re: resolv.conf search list truncated - not to specification
I can confirm this bug, and the behavior noticed by the original reporter that reinstall or dpkg-reconfigure seems to fix the problem. We are seeing this behavior in hardy. ** Changed in: resolvconf (Ubuntu) Status: Incomplete => Confirmed -- resolv.conf search list truncated - not to specification https://bugs.launchpad.net/bugs/172367 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 59375] Re: One DNS by DHCP setting overwrites another
Confirmed. We see same problem in Hardy. ** Changed in: resolvconf (Ubuntu) Status: New => Confirmed -- One DNS by DHCP setting overwrites another https://bugs.launchpad.net/bugs/59375 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192258] Re: avahi should be downgraded to Suggests dependency
> So, if I read your request correctly, moving avahi-daemon from depends > to recommends would be satisfactory? You'd need to move all three of avahi-daemon, avahi-autoipd, and libnss-mdns, because they work in concert. A convenient method may be to create a recommends dependency on a separate "avahi-desktop" package that depends on all three. It's not an optimal solution, but it is a workable one. As I have written at length on many occasions, avahi is insecure and unreliable for users, imposes an unnecessary burden on the Internet at large, and should be deprecated (certainly not installed by default). A "suggests" dependency would require a conscious decision to activate and is much preferred. However, moving "los tres diablos" to recommends would at least allow a user to purge them and still preserve smooth upgrades. -- avahi should be downgraded to Suggests dependency https://bugs.launchpad.net/bugs/192258 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
This bug is documented in http://www.ietf.org/rfc/rfc4795.txt and warned against in the manpage to resolv.conf. ** Changed in: avahi (Ubuntu) Status: Invalid => Confirmed -- mdns listed in nsswitch.conf causes excessive time for dns lookups https://bugs.launchpad.net/bugs/94940 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 82287] Re: [feisty] avahi daemon interacts badly with network-manager
>Seems solved to me in hardy anyone can comment? >I have tried again, and there where "eth0:avahi", "eth0" and "eth1" already up, but no "eth1:avahi". This is because avahi can only configures one interface. To do otherwise would require separate resolver caches for each network interface, in accordance with RFC4795 (http://www.ietf.org/rfc/rfc4795.txt) at Sections 4.3 and 5.4. Implementing such behavior would increase vulnerabilities to denial of service (id. at Section 5.1) and spoofing (id. at Section 5.3) man-in-the-middle attacks and would reduce resolver performance (see manpage of resolv.conf). The security vulnerabilities can be mitigated by following the guidelines suggested in RFC4795 at 5.2, but will not be entirely eliminated, especially in the context of internet cafes and public wifi zones. >there is no reason avahi-daemon should affect Network managers access There is an indirect connection between the two. The problem centers around the way avahi-autoipd interacts with dhcdbd, which both ignore or interfere with the configuration found in /etc/network/interfaces. More generally and fundamentally, networking is unstable in the default installation because IP addresses are allocated using three parallel systems that don't work together very well: dhclient/ifupdown, dhclient/dhcdbd, and avahi-daemon/avahi-autoipd. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz -- [feisty] avahi daemon interacts badly with network-manager https://bugs.launchpad.net/bugs/82287 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 138895] Re: [gutsy] wired static IP doe not hold
*** This bug is a duplicate of bug 38140 *** https://bugs.launchpad.net/bugs/38140 ** This bug has been marked a duplicate of bug 38140 dhclient3 keeps running after ifdown -- [gutsy] wired static IP doe not hold https://bugs.launchpad.net/bugs/138895 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 80900] Re: problems resolving fully qualified domain names in environments where .local is used as a TLD
My company has come up against this problem time and again. Our most reliable solution is to purge avahi-daemon, avahi-autoipd, and libnss- mdns, which allows networking to work automatically. > on a large network avahi plays a large role in finding > shares and printers Printer recognition still works the right way, in part because CUPS depends on avahi client libraries that allow it to hear the printer. (It's rarely a problem anyway because the printer setup can scan for print servers listening on port 9100.) The practice of using .local is problematic in every case because it's not a IANA TLD. (The current legal TLDs can be found at http://data.iana.org/TLD/tlds-alpha-by-domain.txt) Leakage from private networks causes a burden on the IANA servers and needlessly soaks up bandwidth on the Internet at large. (It is estimated that About 1/4 to 1/2 of the 206 traffic sent to the Root DNS Servers are related to the .local zone.) Several recommendations have been floated to solve the problem, but the problem persists. See, e.g., http://www.tools.ietf.org/html/draft-kato-dnsop-local-zones-00 (2003), http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html (2005) (recommending split DNS zones and providing detailed implementation instructions), http://staff.science.uva.nl/~delaat/sne-2006-2007/p21/report.pdf (2007), http://ftp.kaist.ac.kr/pub/internet-drafts/draft-hardaker-dnsops-name- server-management-reqs-03.txt at Section A.1 (2008), http://www.ietf.org /internet-drafts/draft-ietf-dnsop-default-local-zones-04.txt (2008). >From a best practices standpoint, we are recommending to business clients that networks using "example.local" networks (e.g., MS Active Directory networks) change to "local.example.com", and in the rare cases where avahi is useful, reconfigure avahi to broadcast on and listen for "mdns.example.com", "avahi.example.com", or other non-ambiguous FQDN. The public DNS server adds an A record for local.example.com mapping to the IP address of the public resource administering the local namespace, and the private DNS server would be configured like any other server for the namespace. Using this practice, any leakage to the public Internet is handled seamlessly by DNS. Further, in view of several proposals for .local to be recognized as a TLD, any future formalization to the .local namespace would not affect the local network. Best practice for home users or other instances where the network does not have a registered FQDN would be to set the fallback avahi domain to local.avahi.org and add to the /etc/resolv.conf file "search local.avahi.org". Again, any leakage would fail without burden to the Internet (or at least only to the avahi.org domain and not the public IANA servers). Implementation is easily accomplished by editing the resolvconf scripts. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz -- problems resolving fully qualified domain names in environments where .local is used as a TLD https://bugs.launchpad.net/bugs/80900 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 54454] Re: mozilla-firefox printing system is not able to print on more than 1 page
** Changed in: firefox-3.0 (Ubuntu) Status: New => Confirmed -- mozilla-firefox printing system is not able to print on more than 1 page https://bugs.launchpad.net/bugs/54454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 146737] Re: Ubuntu offers no "zero configuration network" or so (unlike Apple)
Avahi implementation of zero configuration network is installed by default. Filer refuses to answer debugging questions from Avahi developer. ** Changed in: kdenetwork (Ubuntu) Status: New => Invalid -- Ubuntu offers no "zero configuration network" or so (unlike Apple) https://bugs.launchpad.net/bugs/146737 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 146737] Re: Ubuntu offers no "zero configuration network" or so (unlike Apple)
Bug report is both invalid and incomplete. Report is invalid because premise of bug that "Ubuntu offers no zero configuration network" is incorrect. Avahi is an implementation of zero configuration and ships with Ubuntu by default. Report is incomplete because filer refuses to answer debugging questions from Avahi developer (who is supportive of bug filer's position), is offended by disagreement on Avahi's technical merits, and is dismissive of suggestions for alternative methods to accomplish desired results. ** Changed in: avahi (Ubuntu) Status: Confirmed => Invalid -- Ubuntu offers no "zero configuration network" or so (unlike Apple) https://bugs.launchpad.net/bugs/146737 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 146737] Re: Ubuntu offers no "zero configuration network" or so (unlike Apple)
>I am not a computer security specialist but I think there must be a way >of doing this, and doing this in such way that it is safe for the >system. There are several existing safe methods to transfer files between computers. The method you describe is not safe because any other computer connected via the ethernet port would be able to get the files off your system. Thus, every time you connected to the Internet, everyone in the world could get your files. It's the way Windows 98 did it, and one of many reasons why Windows is a security nightmare. >I do not know what DHCP is. Neither do I know what NAT is. DHCP is the standard protocol by which the computer negotiates for an IP address. A router usually has a built-in DHCP server that administers which computers get which IP address. NAT is the system of sharing a single Internet connection among several computers. Technically, NAT is independent of DHCP, but in practice, NAT and DHCP work together. The "average user" is connected to the Internet using a computer that already automatically asks the router for a connection to the network (using DHCP), and the router automatically allocates the IP address and connects the computer. Once connected, all the computers on the network can share data and files. If you really do have two stand-alone computers and you want to connect them together, install the dhcp3-server package on one of the computers and use a crossover cable to connect the two together. If you don't have a crossover cable, you can connect them via a switch or hub. >I might add that connecting B and C via USB cable would probably be >similarly acceptable for the average user. This is appropriate for another discussion, but in short, connecting two computers using a regular USB cable is dangerous. You could well end up frying your motherboard. It is possible using a USB crossover cable, but that's outside the scope of this discussion. -- Ubuntu offers no "zero configuration network" or so (unlike Apple) https://bugs.launchpad.net/bugs/146737 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192258] Re: avahi should be downgraded to Suggests dependency
> Can you name any of such companies? No, because they are my customers and they don't cotton to me telling the world about their internal decision-making. -- avahi should be downgraded to Suggests dependency https://bugs.launchpad.net/bugs/192258 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 146737] Re: Ubuntu offers no "zero configuration network" or so (unlike Apple)
> Application scenario: A works on his notebook B and wants to easily get > 1GB to his workplace desktop C. What he would expect would be the > following: > > - He connects B and C using an ethernet cable. > - C says: "Computer B has been connected to your computer. Do you > - want to allow the B to copy or delete user data on your hard disk?" I cannot disagree more forcefully with this suggestion, on many levels. >From a usefulness standpoint, the suggestion would involve much work for little benefit. The "Application scenario" starts with a rather simple desired task: move 1GB from one computer to another. There are a number of methods for transferring files between computers without further expanding the insecure and unstable avahi/bonjour/zeroconf morass that already exists (and which, IMNSHO, should be deprecated and ripped out of every computer connected to the Internet). Network protocols have already been carefully engineered to accomplish the desired result. The supposed expectation of the user to be able to connect two computers together by an ethernet cable and *by default* share files assumes an absence of security on both machines that is a throwback to Windows98. In the "Application scenario", the user would simply connect the laptop to the workplace network. I daresay that there are few, if any, networks connected to the internet that do not already have a router/DHCP server with NAT firewall (and if such networks exist, they are open targets for crackers and should be disconnected from the Internet immediately). The network's DHCP server will give the notebook an IP address and the two computers can share the information over the already established network, according to the security setup of the network. Again, I vote that this alleged "bug" be closed as invalid. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz On Fri, May 30, 2008 at 8:34 AM, oss_test_launchpad <[EMAIL PROTECTED]> wrote: > Maybe I put this wrong. I do not support any special program to solve > this. All I am saying is that Ubuntu users, unlike Mac users, cannot > just connect two computers with a cable and in this way get data from > one computer to another. This would, however, be an important comfort > feature. > > - C says: "Computer B has been connected to your computer. Do you want to > allow the B to copy or delete user data on your hard disk?" > - Same vice versa. > - A clicks "Yes" on "B" and "C", then enters the "B" user password on B and > the "C" user password on C and can now copy data in both ways. > > With my limited knowledge of network technologies, I would assume that > all programs that would be necessary for that already are on every > Ubuntu system. It's just that you would have to configure them in such > way that the above mentioned procedure would work. Maybe I am wrong > here. > > ** Also affects: kdenetwork (Ubuntu) > Importance: Undecided > Status: New > > -- > Ubuntu offers no "zero configuration network" or so (unlike Apple) > https://bugs.launchpad.net/bugs/146737 > You received this bug notification because you are a direct subscriber > of the bug. > -- Ubuntu offers no "zero configuration network" or so (unlike Apple) https://bugs.launchpad.net/bugs/146737 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 181017] Re: package tftpd-hpa None failed to install/upgrade: subprocess post-installation script returned error exit status 71
*** This bug is a duplicate of bug 227881 *** https://bugs.launchpad.net/bugs/227881 ** This bug has been marked a duplicate of bug 227881 tftpd-hpa does not use /etc/default/tftp-hpa options -- package tftpd-hpa None failed to install/upgrade: subprocess post-installation script returned error exit status 71 https://bugs.launchpad.net/bugs/181017 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 227881] Re: tftpd-hpa does not use /etc/default/tftp-hpa options
Confirmed. The solution suggested here would fix bug 181017. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz ** Changed in: tftp-hpa (Ubuntu) Status: New => Confirmed -- tftpd-hpa does not use /etc/default/tftp-hpa options https://bugs.launchpad.net/bugs/227881 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 181017] Re: package tftpd-hpa None failed to install/upgrade: subprocess post-installation script returned error exit status 71
*** This bug is a duplicate of bug 227881 *** https://bugs.launchpad.net/bugs/227881 Same problem here. Upgrading from Gutsy to Hardy. Output of "aptitude install tftpd-hpa": Preconfiguring packages ... (Reading database ... 375171 files and directories currently installed.) Preparing to replace tftpd-hpa 0.43-1.1ubuntu1 (using .../tftpd-hpa_0.48-1ubuntu1_i386.deb) ... Stopping HPA's tftpd: in.tftpdNo in.tftpd found running; none killed. invoke-rc.d: initscript tftpd-hpa, action "stop" failed. dpkg: warning - old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... Stopping HPA's tftpd: in.tftpdNo in.tftpd found running; none killed. invoke-rc.d: initscript tftpd-hpa, action "stop" failed. dpkg: error processing /var/cache/apt/archives/tftpd-hpa_0.48-1ubuntu1_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 1 Starting HPA's tftpd: in.tftpdinvoke-rc.d: initscript tftpd-hpa, action "start" failed. dpkg: error while cleaning up: subprocess post-installation script returned error exit status 71 /var/log/syslog shows: in.tftpd[8716]: cannot bind to local socket: Address already in use "ps -e | grep ftp" finds nothing. "netstat -l | grep ftp" shows: udp0 0 *:tftp *:* "grep tftp /etc/services" shows: tftp69/udp Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz -- package tftpd-hpa None failed to install/upgrade: subprocess post-installation script returned error exit status 71 https://bugs.launchpad.net/bugs/181017 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 229754] [NEW] oem-config deletes first user
Public bug reported: Configured system under oem-config. Executed oem-config-prepare from graphical interface. On first boot, system asks for user information and appears to create user, but user cannot log in. On reboot into recovery mode, group of username is available, but user of username is not available and username's home directory is gone. I cannot tell for certain if the user was never created or was created but immediately deleted as part of oem-config clean up. I think this is a regression because the changes made to oem-config intending to delete the package on firstboot (see bug 145281) appear to have caused the problem. Thus, the fix for Bug 145281 appears to have been too draconian and caused unintended consequences. This bug has been replicated in our factory on both Ubuntu-gnome and Kubuntu. Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz ** Affects: oem-config (Ubuntu) Importance: Undecided Status: New ** Description changed: Configured system under oem-config. Executed oem-config-prepare from - graphical memory. On first boot, system asks for user information and + graphical interface. On first boot, system asks for user information and appears to create user, but user cannot log in. On reboot into recovery mode, group of username is available, but user of username is not available and username's home directory is gone. I cannot tell for certain if the user was never created or was created but immediately deleted as part of oem-config clean up. I think this is a regression because the changes made to oem-config intending to delete the package on firstboot (see bug 145281) appear to have caused the problem. Thus, the fix for Bug 145281 appears to have been too draconian and caused unintended consequences. This bug has been replicated in our factory on both Ubuntu-gnome and Kubuntu. Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz -- oem-config deletes first user https://bugs.launchpad.net/bugs/229754 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 228910] Re: Streamline release upgrades, text mode upgrading
This is the same problem as we had upgrading from feisty to gutsy. Simply replacing gutsy with hardy in /etc/apt/sources.list and upgrading with aptitude is much easier, faster, and less error-prone than the "recommended" upgrades using the graphical interfaces or than using the "do-release-upgrade" script. I'd be happy to help with improving the upgrade experience, but it's hard to assist when there's no documentation. ** Changed in: ubuntu Status: New => Confirmed -- Streamline release upgrades, text mode upgrading https://bugs.launchpad.net/bugs/228910 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 148454] Re: console-kit-deamon spawns too many threads
@ Jonathan Rogers >However, currently it says nothing about what the threads are used for or what would be an appropriate number of threads. Of course, it's not documented, so no one knows, which is why the bug report exists in the first place. Experienced users and system engineers know that generally something is wrong if several dozen identical, dormant processes are running in userspace with no apparent usefulness. >I haven't seen any strong evidence that it deserves as much attention . . . . I'm not exactly sure what you are trying to accomplish in this thread. If this issue isn't worthy of attention, why are you paying it so much? Saying that there are other problems to solve is stating the obvious and not helpful to solving any of them. If you know of a reason this problem should not be fixed, do tell. If you have other helpful information, share it. If you have solutions to this or other problems in the stack, go solve them. Said another way, if you know of bigger fish to fry, perhaps you should get your skillet out and fry them. Happy Trails, Loye Young -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 148454] Re: console-kit-deamon spawns too many threads
I've written an email to the author of ConsoleKit inquiring about the issue. What follows is the text of my correspondence: >Mr. McCann, > >Users on Ubuntu systems (myself included) are finding that ConsoleKit >generates several dozen processes and doesn't seem to release them. >Although no one of the processes takes up much memory or state, the aggregate >amount is significant, especially on resource constrained >systems. > >Is this expected behavior? If yes, could you shed some light on why so many >processes and threads need to remain open? If no, do you have any >idea whether the problem is in ConsoleKit or in the Ubuntu implementation of >ConsoleKit? > >From what I've read about ConsoleKit, it seems to be a sensible solution to >managing users and hardware access for desktop and other GUI >applications. However, the sheer number of running processes has many asking >whether the game is worth the candle. Your guidance on the >relative benefits and costs and on expected implementation of ConsoleKit would >be much appreciated. > >See the forum discussion at >http://ubuntuforums.org/archive/index.php/t-556272.html, and the bug report at >https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/148454. Happy Trails, Loye Young -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 148454] Re: console-kit-deamon spawns too many threads
@Jonathan Rogers -- There are at least two major flaws in your analysis. First, your analysis presumes to know ex ante the configuration of the computer and the use to which the package will be put. Second, it does not take into account the need for simultaneously managing multiple users and multiple hardware connections to the computer, in both graphical and console modes. Various configurations-- Using Linux as a desktop platform provides a degree of flexibility and power that was hitherto simply unavailable. The significant advances in software technology is fueling the explosive growth of recycled, mobile, and embedded devices, most of which are running or are planned to be run on Linux. The overall efficiency gains are attributable to much more than just the kernel. Because open-source developers have a penchant for eliminating inefficiencies and wasted resources, the entire software stack is significantly faster and lighter than legacy operating systems. It is true that resource-restrained systems must make often difficult choices, but part of the work we do is to give the community more choices in order to solve common problems. One example of an effort to deliver the desktop to low-resource systems is the Xubuntu distribution, which is specifically designed to run on systems with 256M of RAM. Other low-resource desktop solutions are, e.g., DSL, Puppy Linux, Fluxbuntu, aLinux, Zenwalk, DeLi Linux, Wolvix. My company is currently developing a desktop solution to manage servers with a graphical interface. In such use-cases, every megabyte of wasted resources makes a difference, and eliminating the waste is a never-finished project. Eliminating 2.5 MB of resource usage from one process is often a terrific improvement. In addition, each freed thread reduces state usage, which can make a significant improvement in performance in many situations. Console-kit is intended to solve in a platform-independent manner several problems related to the management of multiseat configurations. See http://lists.freedesktop.org/archives/hal/2007-January/006996.html. As desktop environments are coalescing around the DBUS architecture, common solutions such as console-kit will be invaluable to interoperability among applications and among desktop environments. Because the common solutions will be used in such disparate situations, resource utilization must be zealously optimized throughout the stack. Happy Trails, Loye Young Isaac & Young Computer Company Laredo, Texas http://www.iycc.biz -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 148454] Re: console-kit-deamon spawns too many threads
>i have checked "Hide userland threads" and it solve the issue, Hiding the threads doesn't solve the issue; it merely hides the problem. The problem is that the threads are running, not that the list of running threads is too long. On Mon, Apr 28, 2008 at 4:58 PM, Aeffenwell <[EMAIL PROTECTED]> wrote: > Hi, > I've noted that i had this problem for other programs like skype, firefox > (and npviewer) > in the setup, i have checked "Hide userland threads" and it solve the > issue, > and for console-kit-daemon too. > > I don't know if it can help. > Bye > > -- > console-kit-deamon spawns too many threads > https://bugs.launchpad.net/bugs/148454 > You received this bug notification because you are a direct subscriber > of the bug. > -- Loye Young Isaac & Young Computer Company Laredo, Texas (956) 857-1172 [EMAIL PROTECTED] ** Attachment added: "unnamed" http://launchpadlibrarian.net/14018112/unnamed -- console-kit-deamon spawns too many threads https://bugs.launchpad.net/bugs/148454 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 123713] Re: package description needs rewrite
Not fixed ** Changed in: ubufox (Ubuntu) Status: Fix Released => Confirmed -- package description needs rewrite https://bugs.launchpad.net/bugs/123713 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs