Re: Checksums Done Right
>> This is great until md5 collision attacks[1] and >> kernel-based rootkits are used on your system (common these days). > > Do you have any references to the use of md5 collision attacks being > common? Ahh, you are correct. I was thinking of kernel-based rootkits being common. I have no evidence that states collision attacks are currently common. To clarify, it's trivially easy, using freely available source code[1] (31 secs/file now), to attack a system so that some valid executables have the same checksum as the vendors distributed copy but do something completely unexpected. If nothing else changes with those files (permissions, size, owner, group, time) it would easily fool many admins. > It's possible that I'm missing the point here, but what guarantees do > you have that you can trust your Dom0? Well, it's running Ubuntu of course! ;) The way we run our dom0s is that they are not listening on the network, they have no users (other than admins), run little (mainly ssh-client) non-base install software, and they are physically secure. We have not yet seen a domU -> dom0 escalation attack (anyone else?). It may come eventually but thankfully it's not here yet. We could also build Xen from source, and examine the Xen diffs in great detail, but we aren't *that* paranoid, yet. Really the only known way to compromise a system and kernel in this environment is to control the mirror/media, control the Xen build environment or, control ring -1 (think "blue pill"[2] - heh installing Xen inside an already virtualized system would quickly degrade the quality of life). So, reducing the circle of trust is a very good thing. Trusting your vendors and yourself (ie your mirror, admins, and process) is about as good as it gets. Scott - [1] http://cryptography.hyperlink.cz/MD5_collisions.html [2] http://en.wikipedia.org/wiki/Blue_Pill_(malware) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checksums Done Right
> Right, but being able to create a collision isn't the same as being able > to create a *useful* collision. You need to be able to alter the > functionality of the program in a very specific way in order to use it > to escalate privileges. Escalation of privileges is one attack, yes. Although the type of "attack" I'm talking about is for users that already have the ability to write a root-owned binary. I'm describing more of a DoS attack that basically just keeps admins scratching their heads. It doesn't have to be a useful collision to cause headaches. The main point is that md5 is broken and should be retired[1] (note: that's the "R" in RSA writing that "md5 is broken" not just me). > So the real benefit is that you can do this on a live system, rather > than having to reboot to known-good media? Potentially, yes. Of course I envision malicious kernel modules being created that remove themselves from the filesystem while running then at the last minute before shutting down write what's necessary to load themselves on boot again. In that case you'd have to shutdown the system to be certain. The additional benefit is that we can link the file validation to the maintainers version. Tripwire doesn't do this but debsums does (kinda - it uses a cache instead of the known good from a central source like a mirror). We see a need for a centralized tripwire-like system that only trusts the maintainers/distributions and distrusts both the running kernel and any local database of installed packages/files. Oh ya, we want it to be cross-distribution too. > (I'm sceptical about the idea > of attackers being able to virtualise a system without anybody noticing. > Latency of privileged instructions would change in a pretty obvious way) Then I invite you to join the ongoing "blue pill" debate. That is really outside the scope of CDR but still an interesting attack vector none-the-less. We assume you get the "high ground" first. Scott - [1] http://mail.python.org/pipermail/python-dev/2005-December/058850.html -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checksums Done Right
> needs replacing immediately. So if not immediately, is there a timeline for replacing md5 in the deb package format? I'm not familiar with how these edge cases work so maybe that's a question for the dpkg maintainers. Regardless, I imagine the best way to replace md5 would be to offer both md5 and sha256 concurrently before removing md5 eventually. >> > So the real benefit is that you can do this on a live system, rather >> > than having to reboot to known-good media? >> >> Potentially, yes. Of course I envision malicious kernel modules being >> created that remove themselves from the filesystem while running then at >> the last minute before shutting down write what's necessary to load >> themselves on boot again. In that case you'd have to shutdown the system >> to be certain. > > With modern hardware the sensible thing to do is just to boot from CD. With modern hardware shutting a dom0 down might mean taking out 10+ active, virtualized servers (in a HA environment it means live migrating those other servers). Assuming your dom0 is secure, rebooting only the domU you wish to check is sufficient and ideal. I expect tools to emerge that will allow one to analyze/validate a domU's kernel, loaded modules, and memory from the dom0 but until then shutting down individual domUs will have to do. Scott -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checksums Done Right
> Yes, if you're already running in a virtualised environment then > providing a mechanism for checking the system makes sense. I'm just not > sure it's a compelling reason to move from a non-virtualised system to a > virtualised system. Indeed. I don't expect an integrity scanner like CDR to be *the* reason people start using virtuali[sz]ation. There are already enough compelling reasons to use it (and to stay away for that matter). As an admin with the budget to purchase halfway decent hardware and spend some time on design it makes my life much easier, so I prefer it. > so you should be able to scan the filesystem from the > dom0 without shutting it down Yes, at least until rootkits hide themselves in memory like I described before. > or using LVM. Yes, but beware of staleness due to disk caching. Of course an LVM snapshot is by definition stale. Scott -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
In [EMAIL PROTECTED] on Mon, 15 Oct 2007 19:24:47 +0100, Scott James Remnant spake thusly: > On Tue, 2007-10-16 at 03:46 +1000, David MacKinnon wrote: > >> On 10/16/07, Scott James Remnant <[EMAIL PROTECTED]> wrote: >> >> > You mentioned udev in your mailing list post -- clearly you have some >> > reason to suspect it should be fixed there, otherwise why mention it >> > all? >> >> Because the other person in the bug thought so enough to ask the udev >> maintainers opinion, which was never given? >> > The udev maintainer (me) has an unanswered question on the bug ... which > is why I was a bit miffed that you were blaming udev when the maintainer > clearly hasn't got the information he needs. > > Scott If you are referring to your "What causes the race, do we know?" question, then I guess we must lay the blame on Reinhard Tartler who has not had the opportunity (perhaps he has higher priories in his life than developing software - assuming he's unpaid like most FLOSS developers are) to respond.* On a related note, the last comment (as of this writing) in thhis bug is a week old and it's from none other than Richard. He asks "So are we pushing a gutsy release next without this patched anywhere?" Well Richard, since your question has been ignored, I'll do my best to answer it for you. The answer is: "Yes, that's what we're doing". *FLOSS' biggest downfall. -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
In [EMAIL PROTECTED] on Tue, 16 Oct 2007 03:25:36 +, Scott spake thusly: > On a related note, the last comment (as of this writing) in thhis bug is > a week old and it's from none other than Richard. He asks "So are we > pushing a gutsy release next without this patched anywhere?" > > Well Richard, since your question has been ignored, I'll do my best to > answer it for you. Oops.. I meant David (not Richard). -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Hardy Alpha-4 synaptic error
Try opening a terminal and typing 'gksu synaptic' or 'gksu update-manager'. Regards, Scott Richard Mancusi wrote: After a clean install (i386 desktop) I receive an error when attempting either: 1. System/Administration/Update Manager 2. System/Administration/Synaptic Package Manager An error occured The following details are provided: E:ERROR: could not create configuration directory /home/root/.synaptic - mkdir (2 No such file or directory) I do have a directory /root/.synaptic and obviously there is no such thing as /home/root where it appears to be looking. -rich signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Lots of Kernel related brakage in Lucid (amd64)
Christopher James Halse Rogers spake thusly: > On Mon, 2010-03-15 at 05:09 +0000, Scott Beamer wrote: >> Just downloaded the latest nightly live CD and installed. >> >> After reboot computer freezes at splash screen. > > This might be plymouth; see if hitting SysRq+Alt+k kills the splash > screen and brings up X. I'm back on the laptop now (previous reply was from my desktop) and I tried your suggestion here. Nothing happened. I had to ctrl+alt+delete and restart. So it's VERY broken if one is installing from the today's (yesterday's) daily live CD You sure this isn't a Kernel-related issue? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: IronPython and Mono are very old. How can we get an update?
On 03/18/2011 05:08 PM, Vernon Cole wrote: Hello. I am new to the list, please forgive and let me know if this is not the appropriate forum. I was very pleased when IronPython appeared on synaptic -- even though I was a bit concerned that the version was 2.6B2 about the time that 2.6 was released. No problem, given the regularity with which Ubuntu updates their packages, so I waited. A short while ago, I contributed a patch to the IronPython standard library. I received a somewhat acid comment that my patch had not been tested on Mono/Linux. True, it had not. I downloaded the current source of IronPython from github, and discovered that I cannot build, because my version of Mono is too old. In order to get a current version of Mono, my sources suggested, just switch to Redhat!!! WTF?! _Redhat_ has the latest stuff and Ubuntu is dragging in ancient history? Something is wrong here! IronPython 2.7 was released last week, with my patch and without the requested test. Other than grouching on this list, what can I do to get my favourite distro up to speed? -- Vernon Cole You can always go the source and compile it yourself...http://www.go-mono.com/mono-downloads/download.html Find the maintainers of the package and I'm sure they'll welcome any contribution. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Did I miss some package so I can not compile read_write_mutex.hpp in boost?
On 08/03/2011 09:55 PM, eric wrote: dear boost progamers: when I tried to compile from my g++4.5.2 a simple file which include #include --- root_at_eric-laptop:/home/eric/cppcookbook/ch12# g++ -lboost_thread Example12-3.cpp Example12-3.cpp:3:45: fatal error: boost/thread/read_write_mutex.hpp: No such file or directory compilation terminated. - and I check from / of my ubuntuLinux (10.04) with boost 1.46.1 I can not find any file name as read_wirte_mutex.hpp - root_at_eric-laptop:/# find . | grep read_write_mutex.hpp root_at_eric-laptop:/# --- and I can not digout from web how to make it compile under gcc/g++ plz help, Eric You could try asking herehttps://svn.boost.org/trac/boost/ticket/578 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Did I miss some package so I can not compile read_write_mutex.hpp in boost?
On 08/03/2011 10:59 PM, scott wrote: On 08/03/2011 09:55 PM, eric wrote: dear boost progamers: when I tried to compile from my g++4.5.2 a simple file which include #include --- root_at_eric-laptop:/home/eric/cppcookbook/ch12# g++ -lboost_thread Example12-3.cpp Example12-3.cpp:3:45: fatal error: boost/thread/read_write_mutex.hpp: No such file or directory compilation terminated. - and I check from / of my ubuntuLinux (10.04) with boost 1.46.1 I can not find any file name as read_wirte_mutex.hpp - root_at_eric-laptop:/# find . | grep read_write_mutex.hpp root_at_eric-laptop:/# --- and I can not digout from web how to make it compile under gcc/g++ plz help, Eric You could try asking herehttps://svn.boost.org/trac/boost/ticket/578 Sorry. Meant here...https://svn.boost.org/trac/boost/newticket -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
ldap-account-manager post-script error 1
have tried many different commands with both apt and dpkg --force still cant get system to properly remove with the installlation of apache2, please can you help me with the proper syntax for the removasl override -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Which third party repository do you use?
On Sat, 2007-01-06 at 17:30 -0800, Constantine Evans wrote: > Perhaps it would be better to allow repositories to add an extra file > that would contain a title and description, and then use that > information? Such a method would require that repositories do extra work > to support it, but I expect that most safe repositories would do so. This was my thought exactly. It would be fairly trivial to add a text file to the Apt repository that had a simple one-line description of the repository's contents (perhaps in multiple languages). Hell, it's not much more work than setting up the repository in the first place - I'd do it the next time I upload a Wine package. This also seems like a far more elegant approach than trying to maintain a config file of known repositories in the system somewhere. Such a file would either become quickly out of date or a pain to keep current - a change would require the repository owner contacting the maintainer of the config and then having him update it and then having the user download the update. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Which third party repository do you use?
On Sat, 2007-01-06 at 13:57 -0600, Aren Olson wrote: > Here's a few useful repositories I use (copied from sources.list): > ## Latest Wine > ## Site: http://winehq.com/site/download-deb > deb http://wine.budgetdedicated.com/apt/ edgy main > deb-src http://wine.budgetdedicated.com/apt/ edgy main By the way, I've added an apt key for this now. It's here: http://wine.budgetdedicated.com/apt/387EE263.gpg Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Transition to Ubuntu specific Maintainer: fields
On Mon, 2007-02-19 at 14:32 +0100, Lut!n wrote: > > > 2007/2/19, Martin Pitt <[EMAIL PROTECTED]>: > Hello Ubuntu developers, > > a fair while ago, the Debian project collectively decided that > Ubuntu > source and binary packages should not carry Debian's > maintainers in > their Maintainer: field any more. Instead, we shall preserve > them in > the Original-Maintainer: field and put an Ubuntu specific > contact into > Maintainer:. Please see the specification [1] for details. > > With the recent dpkg upload [2], this now gets enforced. I. e. > dpkg-source (called from dpkg-buildpackage and debuild) > refuses to > create a source package if the version number indicates Ubuntu > modifications, but the Maintainer address is not Ubuntuish. Does this mean I need an @ubuntu.com email address? I maintain a universe package (Wine). Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[Bug 49221] How to solve it, and why I'm not fixing it.
Launchpad #49221 is a high priority bug caused by the 13_smoother_fading patch. I will describe the cascade of issues that triggers it. Next, I will enumerate some user workarounds. Finally, I will explain why I'm not fixing the issue: It is well known gnome-session is in need of a refactoring due to feature creep. Among other things, it handles initial client startup, the splash screen, assistive technologies, DBUS, keyring, startup sounds, the logout dialog, proxying of GDM actions (suspend/hiberate/logout/etc.) to other software (gnome-power-manager)... and session management. That list does not include the deprecated features it still has code supporting. On top this, we (downstream Ubuntu) apply 12 patches of varying levels of intrusiveness. Under this weight, multiple things have given. The symptom for bug #49221 is, upon return from a software suspend, a user's desktop appears partially locked up to 30 minutes. (maxint microseconds = 35 minutes) The issue is triggered by 13_smoother_fading's flawed implementation. 13_smoother_fading is intended to improve the quality of the faded background that appears with the logout dialog. Specifically, the original fading code relies upon GTK timeout callbacks. These are often irregular and therefore the resulting fade was irregular. The new fading code adds a usleep call designed to regulate the speed. Session management occurs across UNIX pipes between clients to the session manager. Managed clients connect to a pipe and coordinate with session manager their state. The common client implementation blocks while waiting for a response from the session manager. If a session manager locks up, most managed clients will not appear to have executed. In reality, they will be in blocking before they have been realized. With all that in mind, the bug occurs when a user triggers the logout dialog. While the fade is occurring, the user clicks the suspend button. Multiple bugs paths can occur here. Suffice it to say, the timeout is improperly canceled and the next time the usleep is called, a time-skew issue occurs so the timeout is a number near MAXINT. (depending on the duration of suspend) Since a usleep is used, no other code is executed in g-s-m. And therefore, all managed applications block. This issue does not occur in the upstream code. Their algorithm is broken in other ways that can cause session management issues in extreme cases. However, the fade code explicitly checks for a time-skew and aborts if one is detected. Regardless, they use timeout callbacks. So, even in a worst case situation, session management is still being handled. In summary, gnome-session sucks. 13_smoother_fading sucks more. And it's all a pain to properly fix. (The same code is used in libgksu. But no one hits that race condition in practice.) What can our user's do? Not suspend via the logout dialog. gnome-power-manager's battery icon can be clicked for suspend/hibernate actions. Also, closing a laptop lid will (usually) work. Share and enjoy. Why am I not fixing this bug? Because even fixing this particular issue leaves fistfuls of other serious issues in the same flawed code-path. Our downstream g-s-m is fairly mangled, and the version upstream is not much better. I'd rather engage in a refactoring. But, I am a busy student and not the upstream maintainer. Writing the following is easier than trying to figure out how to get a patch proposed in main. (At least Universe has clear rules...) Add a skew check before the usleep. Or, have a maximum cutoff. The end. -- Scott Robinson <[EMAIL PROTECTED]> http://quadhome.com/ signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Desktop responsiveness in Feisty (vs Edgy)
Sitsofe Wheeler wrote: > Hi, > > Has there been a change to which preemption patches are included in the > default Ubuntu kernel used in Feisty? I ask because I seem to have > noticed far more stutters (both when sound is played and when moving > things like the mouse pointer in X) and periods of up to half a second > where interaction is not possible. > I think what you want is to install linux-lowlatency. It should give you more responsiveness at the cost of battery life (if your on a laptop) and a slightly busier processor. Once you have installed it, reboot into the new lowlatency kernel. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu derivative package naming guidelines
One thing to take advantage of is the use of the ~ character, which APT treats as "lower" than a package not containing it. This allows version "2.4~unofficial-backport" to be replaced by version "2.4" When derivative packages are being made with the expectation that the user will eventually replace them (say, when a newer version of Ubuntu comes out), then the use of the ~ can avoid breakages. Thanks, Scott Ritchie On Thu, 2007-03-15 at 18:24 -0500, David Farning wrote: > One of the challenges of creating the Derivative Team [1] is managing > the chaos introduced by the large variety of distributions[2]. > > As such, I would like to discuss some package naming guidelines for > Ubuntu based derivatives. > > The two basic uses cases are customized packages and new packages. > > 1a. The French localization team is interested in customizing a package > to make it local specific. > > 1b. The Newbuntu organization is interested in shipping a non-standard > version of a package. > > 2. The Newbuntu organization is interested in shipping a package that is > not in the Ubuntu archives. > > The catalyst for this discussion is avoiding the difficulties presented > when debugging and upgrading automatics packages. > > 1. We want to make it obviously clear where a particular packages came > from for debugging purposes. > > 2. We want to make it obviously clear when upgrading that a non standard > upgrade path is being taken. > > Would it be appropriate to establish a standard where customized, > non-standard, or new packages are prefaced by their distribution name. > > For example: > > firefox becomes Newbuntu-firefox > mplayer becomes automatic-mplayer > > This follows that established pattern of ubuntu-desktop becoming > kubuntu-desktop. > > 1. wiki.ubuntu.com/DerivativeTeam > 2. wiki.ubuntu.com/DerivativeTeam/Derivatives > > thanks > -- > David Farning <[EMAIL PROTECTED]> > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Tablet PC and Summer of Code in Ubuntu
Hi, I just wanted to call to the Ubuntu list's attention that there is also a discussion of getting tablet PC support into Wine. Developer Dan Kegel even suggested it as a Summer of Code project. I encourage Charlotte (or anyone else interested in tablet PC support) to also give the winehq list a try - they might even help mentor you. Also, if your summer of code project seems to help multiple Google-sponsored projects (eg Ubuntu and Wine), it's more likely to be approved :) Thanks, Scott Ritchie >From the wine-devel mailing list: Re: SoC idea: Tablet PC support (was: pressure sensitive tablet support) On Fri, 2007-03-23 at 18:57 -0700, Dan Kegel wrote: > On 3/21/07, Dan Kegel <[EMAIL PROTECTED]> wrote: > > While looking around for a project idea, I noticed that people > > are starting to ask for pressure sensitive tablet support in > > Photoshop on Wine. Seems like it could be a fun project > > for some Summer of Code student. > > Update: wintab32 is already implemented in Wine, > but there's a new API being pushed by Microsoft > for Tablet PC applications. So the idea is instead > "Get Tablet PC applications working on Wine", focusing > on Tablet PC apps that offer pressure sensitivity, say. > > (I thought that FIrefox's GeckoTip extension used > the new tablet PC APIs, but after looking at the > source, I'm not so sure... I'm sure there are lots of > good demo apps somewhere.) > > This assumes that Tablet PC apps don't yet work on > Wine. I haven't tried... the place to start is probably > to get the Tablet PC SDK (a free download if you have > Windows) and start playing with it. > - Dan > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: RFC: alias tar="tar --backup" ?
On Thursday 17 May 2007 18:18, Micah Cowan wrote: > A user, timothy, describing his difficulties at: > > https://bugs.launchpad.net/ubuntu/+bug/113154 > > describes his frustration as a new user, in discovering the hard way > that tar's default is to overwrite existing files, causing him to lose > important data. > > While I'm opposed to fixing the problem in tar itself, as traditional > usage frequently relies upon this behavior, I don't see why we couldn't > make the experience of using tar interactively a little safer, by > providing a default alias for tar in /etc/skel/.bashrc that backs-up > existing files. > > Comments? The right status for the bug is rejected. System is working as designed. What you might do though is point the bug author (and maybe work with him jointly since you've expressed an interest) in developing a spec to describe system changes to reduce the risk of accidental data loss by new users. That's, I think, the right way to deal with this type of design issue. Also it gives them a chance to be involved in the discussion and the community and feel valued. It still might add up to nothing different than RTFM, but they'll feel different about it and who knows what the result will be. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
I'd like to discuss how difficult it is to add a third party repository
Next to medibuntu, I currently run one of the most popular third party repositories for Ubuntu, the WineHQ APT repository. The problem is that the instructions at this website are too hard: http://winehq.org/site/download-deb Users need to cut and paste two terminal commands and type their password into the command line. They can't be sure what exactly they're doing, nor is it obvious that this will keep Wine up to date whenever I update the package. One user reported not following the instructions at all because of this, and simply giving up. Once installed, navigating to the "third party" tab of the repositories section in Synaptic gives a bit of vague information. No metadata about the repository is available - simply the location where files are downloaded from. There's room for serious improvement here. Users should be able to click download a file on the WineHQ website, then double click on that, enter their password, and then have the repository set up. When I've offered this suggestion before, some developers have complained about potential security risks from making it so easy to hose your system by adding a malicious third party repository. With the current cryptic instructions, though, even if we gave absolutely no information about what this process does we'd be no worse off than we are now - users are already blindly entering terminal commands. If we couple the file-based installation of a third party repository with some sort of simple explanation and GUI prompt, things should work much more smoothly for everyone. Thoughts? Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: I'd like to discuss how difficult it is to add a third party repository
On Fri, 2007-05-25 at 14:41 -0400, Jean-François Gagnon Laporte wrote: > On 5/25/07, Scott Ritchie <[EMAIL PROTECTED]> wrote: > > > > > > With the current cryptic instructions, though, even if we gave > > absolutely no information about what this process does we'd be no worse > > off than we are now - users are already blindly entering terminal > > commands. If we couple the file-based installation of a third party > > repository with some sort of simple explanation and GUI prompt, things > > should work much more smoothly for everyone. > > > > Thoughts? > > > > Scott Ritchie > > > > There was a blog post recently on the planet that explains exactly > what you ask for : > > http://glatzor.de/node/25 > > I didn't know that you could do that with software-properties(-gtk) > until I read this. By the way, credit goes to Sebastian Heinlein for a > well written article. > This looks promising, thank you. I assume this is new in Feisty. But what about the GPG key? Do they still need to add that with a terminal command? Also, is there a way we could lock one apt key to a particular repository (eg, my apt key is only used for checking the winehq repository)? Is there any benefit to doing this? Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: I'd like to discuss how difficult it is to add a third party repository
On Tue, 2007-05-29 at 10:16 +1000, Christopher Halse Rogers wrote: > On 5/28/07, Dean Sas <[EMAIL PROTECTED]> wrote: > > > > Not in Gutsy at least, there's an authentication tab in > > software-properties-gtk, you can press the "import key file" and browse > > to a key file to add that. > > > Since software-properties-gtk is already a mime handler for > sources.list, could we extend s-p to be a mime-handler for a more > general repository-specification file? Something with a format > including such things as gpg key-id and keyserver, comment, and > possibly a list of mirrors. Then a user could click on an "add wine > repository" link, and be presented with a sane dialog verifying that > they really want to add the "winehq.whereever.org/apt" repository, > signed by foo, to their software sources. Exactly, this would be ideal. As it stands the user has to do _more_ steps to use the GUI tools than simply cut and pasting the command lines. The requirement for a universe package is even more onerous. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcing wineui
On Thu, 2007-06-07 at 09:37 +0200, Stephan Hermann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Matt, > > sorry to come back to you a bit late, but work and family needs more > time right now :) > > > Am Tue, 5 Jun 2007 11:27:31 +0100 > schrieb Matt Zimmerman <[EMAIL PROTECTED]>: > > > On Tue, Jun 05, 2007 at 11:32:18AM +0200, Stephan Hermann wrote: > > > Am Dienstag, den 05.06.2007, 09:57 +0100 schrieb Matt Zimmerman: > > > > We are not talking about building wine into gnome-app-install, > > > > only about enabling it to manage installation/uninstallation of > > > > wine applications. Do you feel that this would compromise it > > > > somehow? > > > > > > That I didn't say. An Installation/Removal tool outside wine would > > > be nice (for both of the main desktops) but right now, it wouldn't > > > be that great, just because wine is far away from being stable. > > > Chats with wine core devs gave me the opportunity to see what those > > > devs need: more experienced "hackers" to use a debugger and winedbg > > > to find out what's wrong and file bugreports towards them. With an > > > installation tool inside our infrastructure, it will give us more > > > hassels, because more people are not using free software, but > > > windows software, and more bugreports are flooding our malone with > > > not usable apport bug reports. this is something which we shouldn't > > > want to have. What the winehq devs need is written on > > > http://www.winehq.org/?issue=330, topic Debugging, and this is > > > something we don't have right now. > > > > Let's be clear on a few things: > > > > - No one is suggesting that we ship Windows applications to Ubuntu > > users > > No, but having "wine" more integrated then it should, gives the User > the opportunity to not use unix natives. They will always use what > they know, even under Linux...but this is another thing. So? If a user wants to use eMule or Filezilla, why shouldn't we make it easier to do that? With the right interface, we could make the use of some Windows applications easier on Ubuntu than Windows itself. Many of these already work, despite Wine's beta nature. That right there is a powerful use case for potential switchers. > > > > > - According to this thread, there is already sufficient developer > > interest to write an installation/removal tool. I am simply > > suggesting that it makes more sense to do that work inside an > > existing installation/removal tool rather than creating a new one. > > If someone wants to work on this, there is no reason do discourage > > them > > Yes, do they know what happens to wine when they need to update some > stuff? Changes in the wine registry needs sometimes the complete > removal auf the local .wine directory. For what do I need an > application removal tool, when a rm -Rvf .wine helps here? > One thing that should be added is a "wipe and reinitialize" feature to whatever Wine configuration tool gets made. > Many people are using or trying to use their native windows ntfs > partition and run their apps with wine from there. An application > removal tool here would be somewhat fatal. This should be discouraged anyway: it doesn't work, and Wine might break the Windows installation. Windows applications (except "portable" ones) need to be installed in Wine's virtual drive. > > This is the most difficult problem with something like that. > I'm not against such a tool, start to code it, but push it away from > the main install/removal tool. Let it be a plugin for g-a-i or > whatever, but not an essential tool for it. > > > > > - This is something of a pedantic point, but not all Windows software > > is non-free > > Yes, but for that, no one is using wine. You are using wine, because > your tax software is not running natively on linux...and most of the > time even with wine it's not running. Anyways a absolute useless > discussion. I don't buy it. eMule is a great example - there simply is no better ed2k client, since porting it without Wine turned out to be a lot more work than people expected - the lmule and amule projects have never achieved the features of eMule. It's also Windows only, and open source. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Why is vim-gtk in universe?
On Saturday 16 June 2007 23:48, Ralf Meyer wrote: > On Fri, 15 Jun 2007 11:41:30 -0700 > > Micah Cowan <[EMAIL PROTECTED]> wrote: > > However, the bug did lead me to question why vim-gtk is in universe. > > Are there examples of other source packages that produce both > > core-dev and community-supported packages? > > I only know of nmap/nmapfe. There are others. Another example is kdepim. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tue, 19 Jun 2007 18:43:33 +0200 Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote: > * Rejected has been split into Invalid and Won't Fix, where the latter >may be a valid bug or wish-list change that we don't have the wish or >resources to fix. Will 'Won't Fix' bugs show up in default search results? I think it would be good for them to show up to minimize duplicate submissions of things that aren't going to get done. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: > If you are not a developer then it is misleading to set it to In > Progress because nobody is actually working on the fix and it may never > be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:09, Cody Somerville wrote: Top posting fixed. > On 6/19/07, Scott Kitterman <[EMAIL PROTECTED]> wrote: > > On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: > > > If you are not a developer then it is misleading to set it to In > > > Progress because nobody is actually working on the fix and it may never > > > be fixed. > > > > Um, non-developers work on fixes all the time. I did a bunch of them > > before I > > was a developer and I sponsor other people's work now that I am one. > > This just isn't correct. > > > > Scott K > I suppose the question is: What is the definition of a developer? > Generally in Ubuntu/LP terms that means someone who is a member of the Ubuntu Development Team in LP (https://launchpad.net/~ubuntu-dev). Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:24, Henrik Nilsen Omma wrote: > Phillip Susi wrote: > > Henrik Nilsen Omma wrote: > >> If you are not a developer then it is misleading to set it to In > >> Progress because nobody is actually working on the fix and it may > >> never be fixed. > > > > There are those of us who are not developers but do still work on > > fixing bugs ;) > > > > Non developers should be able to set these states if the bug is > > assigned to them. > > I don't think you should assign a bug to yourself if you are not working > on fixing it. IMO you should try to move it along to the Triaged state > as efficiently as possible and bugs should be assigned to the developer > or dev team who is going to fix it. > > I realise that this thinking does not match current triaging policy but > IMO that policy should be changed. Too many bugs are being held up in > half-triaged states. Important bugs are sometimes not getting the > attention they should while less important ones are cluttering up the > field. So is this imposing policy change through system updates without discussing it with those affected or were there people involved in the triaging process that were consulted? > FWIW, I'm not a developer myself, I'm simply looking at ways of making > the triage process more structured and efficient. Currently in LP assigned means this is the person who is expected to take the next step on the bug (for example when I set a bug to needs info, I generally assign it to the reporter to make this clear). I'm not sure how taking away triaging tools aligns with your stated goal? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:57, Henrik Nilsen Omma wrote: > Scott Kitterman wrote: > >> I don't think you should assign a bug to yourself if you are not working > >> on fixing it. IMO you should try to move it along to the Triaged state > >> as efficiently as possible and bugs should be assigned to the developer > >> or dev team who is going to fix it. > >> > >> I realise that this thinking does not match current triaging policy but > >> IMO that policy should be changed. Too many bugs are being held up in > >> half-triaged states. Important bugs are sometimes not getting the > >> attention they should while less important ones are cluttering up the > >> field. > > > > So is this imposing policy change through system updates without > > discussing it with those affected or were there people involved in the > > triaging process that were consulted? > > First, you are mixing up two things. The technical change made to > launchpad has been discussed for a while, including at UDS in Sevilla > where community members participated and the phone lines to the world > were open. > > Second, we are not imposing 'this' policy (that triagers should not > assign themselves) at all. I just gave you my personal opinion. I know > that many disagree with me on that and that I will have to make my case > here in much more detail before in can get any more traction. OK. I guess I missed the meeting. Where is this change documented? Was there a spec? Anything those of us who were unable to participate in UDS could have seen this coming? Restrictions imposed by the technical change are defacto policy. If you change the system, you've changed policy. > >> FWIW, I'm not a developer myself, I'm simply looking at ways of making > >> the triage process more structured and efficient. > > > > Currently in LP assigned means this is the person who is expected to take > > the next step on the bug (for example when I set a bug to needs info, I > > generally assign it to the reporter to make this clear). > > That's what you take it to mean and that's what the wiki suggests. I > happen to think it's not the best way to do it. Traditionally in open > source projects a bug has been assigned to the person intending to fix it. > > > I'm not sure how taking away triaging tools aligns with your stated goal? > > I think I have helped create more triage tools than I have taken away ;) I have no idea. I think here you are taking them away for no good reason that I have seen. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:36, Henrik Nilsen Omma wrote: > Scott Kitterman wrote: > > On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: > >> If you are not a developer then it is misleading to set it to In > >> Progress because nobody is actually working on the fix and it may never > >> be fixed. > > > > Um, non-developers work on fixes all the time. I did a bunch of them > > before I was a developer and I sponsor other people's work now that I am > > one. This just isn't correct. > > OK, so I should have said 'Ubuntu developer' (member of core dev or > MOTU) instead of 'developer'. Lots of fixes are being worked on by > upstreams or other non-Ubuntu developers all the time, but we don't mark > a bug as In Progress unless someone is working on a fix in Ubuntu, or at > least in a remote bugtracker to which we have set an upstream task. > > We would encourage anyone who is a developer to join MOTU and later > core-dev so you can upload fixes directly. If you submit useful patches > you would also very easily qualify for ubuntu-qa. Yes and I was in -qa before I was a 'developer', but that's not the point. There are people who aren't in any team who get their work sponsored by people who are. You've now changed the system to make it harder for those people to assign themselves bugs they are working on. By extension, you've added work for those of us who will be asked to do it for them. Not progress in my book. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 19:28, Henrik Nilsen Omma wrote: > Scott Kitterman wrote: > > OK. I guess I missed the meeting. Where is this change documented? Was > > there a spec? Anything those of us who were unable to participate in UDS > > could have seen this coming? > > The discussion was scheduled on a public webpage, but the Launchpad spec > was not public (and thus I have opened a much larger discussion ...). > I'm CCing the launchpad community contact who might want to comments on > this. > > > Restrictions imposed by the technical change are defacto policy. If you > > change the system, you've changed policy. > > That is true, but I'd like you to recognise that the policy that you > suggested above had been imposed (that bugs should not be assigned to > triagers) is in no way related to this technical change. It is only my > personal opinion and I've stated that twice. I understand that now. Thanks for the clarification. > >>> I'm not sure how taking away triaging tools aligns with your stated > >>> goal? > >> > >> I think I have helped create more triage tools than I have taken away ;) > > > > I have no idea. I think here you are taking them away for no good reason > > that I have seen. > > What has beene taken away? The ability for anyone with an email address > to set bugs to In progress and similar. We have also added 3 new bug > states which I think will be very useful. Yes. So now anyone who is not in -dev or -qa that wants to work on a bug will need to bother someone else to set the status or not set it and risk duplication of effort (or give up on the bureaucracy and go home). Is there evidence that this solves an actual problem? Sott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 20:01, Henrik Nilsen Omma wrote: > If we need to give wider permissions to more people then I'm sure we can > do that, both for triaging and fixing, either through ubuntu-qa or other > teams that we can set up. Even an open team with thousands of members > might be better than just anyone with a launchpad account. The > registration page for that team could refer to triaging guidelines. > > Launchpad does have a certain feature set, and that will gradually > change with input from the user base (many projects, not just Ubuntu). > But how the Ubuntu project decides to use those tools will be decided by > us, through discussions like this and the CC and TB if needed. We can > use the team structure or social mechanisms to give the access we want > to various groups. If that's the process for change, then it appears to me it was ignored. I see the point of the additional states. Time will tell how useful they will be (added complexity may or may not be offset by added information and better workflow). Limiting access to state changes is IMO (and apparently others) problematic and appears to have been done in a vacuum without substantial community input. I'd say we had "the access we want" and it's being changed. Once again, is this change in response to an actual problem? I guarantee you the new approach will be problematic for some. Are you (the royal you of the people doing this to us) willing to accept the responsibility for doing the extra work that people won't be able to do for themselves anymore? Keep in mind a lot of us volunteer because we want Ubuntu to succeed and grow. You've now imposed on me to either devote more of my time to helping non-devs status bugs in LP or see potential volunteers give up. I don't like it a bit. What problem were you trying to solve with this change? Are there significant numbers of examples of bugs set to in-progress by non-devs that weren't actually being worked on? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
the development teams we have formal processes of review and >sponsorship. Submitted work is looked at by more experienced people. Yes and this change does not suite that process well. >This ensures the quality of what is committed remains high and helps >people improve their skills. We currently don't have such a formal >process on the triage side. There will always be a tendency to think >that what we are doing currently is about right, but if you don't try to >make changes you will never test that assumption and will not be able to >find potential improvements. > Asking the community for input BEFORE making the change might have been another approach. Having read your message over several times, I don't think lack of understanding has anything to do with my objections. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wednesday 20 June 2007 13:34, Micah Cowan wrote: > I _might_ not be opposed to the restriction, if we added a new, fairly > open but still moderated group, to include MOTU Acolytes, capable of > setting these states, just to prevent *total* non-developers from > setting to/away from them. That would be better, but still imposes an administrative burden both on unofficial developers and on whoever would have to administer the team. Ironically, virtually all of the bugmail I get dumped on me because a team was incorrectly assigned the bug is because of ubuntu-qa. Personally, I have yet to see in progress misused. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wednesday 20 June 2007 16:27, Jonathan Jesse wrote: >From the converstation, membership in ubuntu-qa grants you access to these > > items as well correct? Simply join ubuntu-qa and that should solve the > problem if I'm correct. In order to join ubuntu-qa you have to show experience with bug triaging. So once again, this is a new barrier to entry for people that want to fix bugs. Bug triaging and bug fixing are two different things. What you propose is like a layer violation in protocol design. I'm glad these changes aren't being imposed immediately, but I don't that they are worth any (even small) discouraging of new volunteers to implement. BTW, driving people who have no interest in triaging to join so they can set status on bugs they are fixing also imposes additional workload on bdmurray (the approver for ubuntu-qa) for no real benifit to him. IMO it's a solution in search of a problem. I have yet to see anyone set a bug to in progress that wasn't actually working on it. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Tuesday 26 June 2007 21:20, Daniel T. Chen wrote: > Hi folks, > > I would like to bring several issues into the glare and to propose a > non-invasive and forward- and backward-compatible (for 6.06 LTS and > Gutsy+1 LTS in particular) resolution to them. > I am particularly interested in further suggestions. Constructive > criticism is always welcome. > I think this proposal makes a huge amount of sense. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Checksums Done Right
So I mentioned this on #ubuntu-devel and #ubuntu-mirrors and some people thought it would be better to discuss it here. Most Ubuntu packages (95% - my estimate) come with MD5 checksums at the file level (in a file called md5sums in control.tar.gz). debsums uses these (well actually a cache stored in /var/lib/dpkg/info/*.md5sums) for doing a *rough* verification that what is installed matches what *should* be installed. This is great until md5 collision attacks[1] and kernel-based rootkits are used on your system (common these days). Tripwire is fine and dandy but assumes you run it on a known good system, uses a local cache, and has no integration into the mirror or packaging system. We have been working on a to-be-open-sourced product we are calling Checksums Done Right (CDR). A colleague gave a talk last week that included some notes about CDR[2]. Basically we've processed the md5sums files in dapper, edgy, and feisty and dumped it into a database. When we update our mirror we update our database. The mirror seems like the best place to offer this type of verification service. We have used it to verify binaries on Xen installations by taking LVM snapshots of the virtualized machine and sending checksums to the mirror using ssh all from the dom0. Our tests show that we can verify a system installation (libraries, binaries, and kernel modules) of up to 12k files in around 4 seconds. This theoretically scales to 5k full machine scans per mirror per day. With that, I have a few questions. 1. What is the timeline for moving to a more robust checksum algorithm (say sha256) for files inside packages? 2. Are there any plans to enforce including checksums for all (non-changing) files in a package (so all debs have a md5sums file - currently around 5% don't)? 3. Are there any plans for including a "isconfig" or "isbinary" flagging system like RPM has? 4. Is anyone already doing this? Scott -- [1] http://www.mscs.dal.ca/~selinger/md5collision/ [2] http://cse.ucdavis.edu/users/bill/virt/virt.pdf [3] http://www.xensource.com -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Configuring for use of gpg-agent by default for Gutsy
One of the goals for KDE in Gutsy is to support S/MIME encryption/signing by default in kmail/kontact: https://wiki.kubuntu.org/KubuntuGutsyPlan One of the requirements for meeting this goal is to set "use-agent" in the ~/.gnupg/gpg.conf of the user. I've done some investigation and it seems to me that there is not a significant risk associated with just doing this generally. If the string is set and gnupg-agent is not installed, pgp signing/encryption still works. All that happens is gnupg prints a warning that no running agent can be found, but it happily asks for a passphrase using the normal CLI interface. The only issue I've found with using gpg-agent with an appropriate pinentry program is a problem in debuild with the way that it destroyed the local environment and then called debsign. This was fixed in the last devscripts upload by Steve Kowalik (seahorse-agent will also now work with debuild). >From a KDE perspective, one side benifit of enabling agent out of the box is that gpg signing/encryption will also work as soon as kmail has been set up for it (i.e. set up the keys to use for signing/encryption). There are no doubt hacks we could come up with to set "use-agent" when kmail/kontact is installed, but it seems to me that setting it by default is the cleanest approach with no real downside risk that I've been able to identify. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Changed behaviour of Apport crash bugs
On Friday 06 July 2007 06:44, Martin Pitt wrote: > * There will be no bug email sent at all until someone marks a bug >as public. This sounds like progress in general, but at least for my personal work flow I tend to rely on bugmail to know that there is something that needs looking into for packages I consider myself the minder for. So now I'm uncertain how I'll even find out about these bugs. Would it be possible/reasonable to send bugmail if the recipient is authorized to look at the bug (e.g. MOTU or core-dev)? Since LP has PGP keys for all such people, private bugs could be encrypted if privacy is a concern. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: apport query
On Tuesday 10 July 2007 19:10, Alex Jones wrote: > System -> Open Source -> Error Reporting > > It would be nice to throw a lot of little items under such a new menu > that are relevant to contributing to the Open Source ecosystem. Wouldn't pretty much everything fit under such a menu item? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Windows-based driver support checker for Ubuntu?
On Tue, Jul 24, 2007 at 12:10:32AM -0400, xt knight wrote: > The IdeaPool had an idea about a "checker" that would notify the user > of Linux's support of his devices. ( > https://wiki.ubuntu.com/IdeaPool#head-840a946630b2112c0d2ca651b11d8a52171564fe) > > I decided to attempt to implement this. How it works right now is > that a modules.pcimap file is provided from /lib/modules/`uname -r`/ > and a few WinNT APIs are used to get a list of PCI IDs from the host > Windows PC. Then, the computer's PCI IDs are checked against that > pcimap file for Linux support. > Before you get too far along, I recommend checking out: http://kmuto.jp/debian/hcl/ That's Debian's hardware compatibility database and it does exactly what you're describing. The full source code is available: http://kmuto.jp/svn/hcl/trunk/ Also, if there was a simple Windows and Mac OS X rich client that could do this all automatically, I think there would be definite value there. -- Scott Robinson | http://quadhome.com/ Q: Why is this reply five sentences or less? A: http://five.sentenc.es/ signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Getting good debugging stack traces from wine apport crash reports
On Wed, 2007-07-25 at 17:46 +0200, Martin Pitt wrote: > Hello fans of wine, > > I already sent this to Scott Ritchie a while ago, but didn't get a > reply, so let's try here. > > When we talked about improving apport to deliver better stack traces > to us in Sevilla [1], someone also mentioned that wine upstream currently > refuses our gdb stack traces for wine crashes. They want to have some > special magic applied to it instead. > > Who would be an appropriate person and/or ML to discuss this with? I > am happy to work with someone to get a good solution for this, but > since I have zero knowledge about wine I cannot do this alone. > > As the spec [1] says in point 6, we can either silence apport for wine > completely (easy solution, I can do it myself), or find someone who > has a clue about debugging wine and winedb who wants to write a proper > apport hook for wine crashes. > > Did someone get curious now? :-) > > Thank you! > > Martin > > [1] https://wiki.ubuntu.com/ApportBetterRetracing > > -- > Martin Pitthttp://www.piware.de > Ubuntu Developer http://www.ubuntu.com > Debian Developer http://www.debian.org > Sorry about not replying, I was gone for a couple weeks. Anyway, the best place to ask is the Wine-devel mailing list. I'll forward your post there. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
On Saturday 28 July 2007 19:28, Tim Hull wrote: > I thought I'd bring up an issue that I see with Ubuntu - and most Linux > distributions as a whole.Anyway, the issue is that once a release is > declared "stable", there are no more updates beyond security updates > available - at least without resorting to ugly tarballs or random > unofficial package repositories. This is all fine and dandy, unless you > need a feature or a bugfix deemed non-critical - especially if it's the > kernel or some other low-level component like Xorg. > > These types of things are covered by neither Stable Release Updates nor > Backports, and as such users who need a new kernel for hardware support or > who need many other software updates are left going about it the old > tarball way or by trying to install software from the unstable > repositories. In my own case, the situation is that the 2.6.20 kernel in > Feisty can't suspend my MacBook. This is fixed in 2.6.22, but to install > this I must either 1) get the Gutsy kernel, in which case I can't install > linux-headers (needs glibc 2.6) 2) compile my own kernel from source, or 3) > run Gutsy. > > I can see many other situations where this come up - simply Google the many > "running Ubuntu on xyz" articles and you'll find countless "recompile > this", "install this from unofficial repository X" etc etc. This may be > fine for me and for most experienced users, but it remans an issue that, > IMHO, must be resolved if Bug #1 will ever be fixed. > > Is anyone in Ubuntu is doing any work on this issue? This could possibly > include expanding backports, but could also entail making it easier to > build from fresh source for the new user (think BSD ports, but easier). If > so, or if there is interest in working on this, I'd love to help - it seems > like an area where much improvement could be made. > > I hope this e-mail doesn't rub anyone the wrong way - I'm NOT asking for > anything to be done specifically for me. I appreciate all the good work > Ubuntu and Debian are doing, and I hope it continues. > > Tim > > P.S. I may send this to debian-devel as well, as this issue is also present > (albeit to a greater degree with their length between stable releases) in > Debian. For LTS releases I agree this is a problem. I also think Ubuntu is addressing it in a sane way. Most of the changes included in the upcoming 6.06.2 are related to supporting newer hardware. My launchpad-foo isn't up to providing a link, but you can find a link of bugs that are targeted for 6.06.2. For non-LTS releases, I'm not convinced there's a sane way to approach this. I'd be curious if you have a specific proposal. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updates post-release/freeze
On Monday 30 July 2007 12:16, Tim Hull wrote: > 2) For unsupported components, Universe (and multiverse) could be updated > on a rolling basis after release. This could be for mere feature updates - > though they would still have to not require new versions of "main" > components. Components in main could have unsupported updates in universe, > though these would have to install alongside the main packages (firefox3, > for instance, could be a Firefox 3 package). A universe freeze could be > maintained, though updates after the fact would merely go in > "universe-updates" instead of "universe". This would supplant the existing > backports system, and would actually parallel what FreeBSD does with its > "ports". This all takes more resources. In Universe and Backports both we do not have sufficient communicty involvement to support the current demand. IMO any proposal for more $STUFF that isn't paid for should also have some thoughts about where the labor to do the work is going to come from. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcement: One Click Installer
On Monday 06 August 2007 17:09, Chris Wagner wrote: > Every time someone comes up with a new, more-intuitive way to install > software on Linux, there seems to be more negative comments about it > than positive. I recall similar comments when Gdebi was proposed, but > it seems to have gone over okay. Gdebi at least uses packages intended for use in the Debian package management system (personally, I think it's a mistake for it to be installed by default, but that's another arguement). What I have yet to see is an automated way to make packages that consistently and reliably work across multiple architectures on diverse hardware. The issue isn't making installation easy, the issue is the reliability and usability of the underlying packages that have not been designed for our packaging system. I could see extending the gdebi UI to support multiple package installation, but before we get into making foreign packages easy to install, I think we should figure out if they are actually going to work reliably enough. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcement: One Click Installer
On Tuesday 07 August 2007 15:57, Krzysztof Lichota wrote: > This is the approach of apt:// protocol. It is not extensible and it > will not make Ubuntu competitive to rich software ecosystem of Windows. > There _must_ be the way for third party software creators to publish > their software easily. Otherwise they will not be interested in creating > their apps for Linux. I spend a lot of time packaging software for the Debian packaging system. It sounds to me like you believe this is a waste of my time because a generally extensible packaging system that will result in reliable installations across diverse architectures and hardware either exists or it trivial to create. Is that right? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcement: One Click Installer
On Tuesday 07 August 2007 16:11, Krzysztof Lichota wrote: > Scott Kitterman napisał(a): > > On Tuesday 07 August 2007 15:57, Krzysztof Lichota wrote: > >> This is the approach of apt:// protocol. It is not extensible and it > >> will not make Ubuntu competitive to rich software ecosystem of Windows. > >> There _must_ be the way for third party software creators to publish > >> their software easily. Otherwise they will not be interested in creating > >> their apps for Linux. > > > > I spend a lot of time packaging software for the Debian packaging system. > > It sounds to me like you believe this is a waste of my time because a > > generally extensible packaging system that will result in reliable > > installations across diverse architectures and hardware either exists or > > it trivial to create. > > > > Is that right? > > No, you got completely the wrong idea. > Deb packages built for specific distro are useful as they provide best > integration with underlying distribution. And One Click Installer does > not at all address the issue of common packaging format or whether DEB > is better than RPM. It is just a convenient way for users to have their > favourite app installed without knowing what their distro is, what their > packaging system is, how to add repository, how to update it, how to add > keys, etc. > OK, so for a Debian system, where do the.debs come from that One Click is needed for? This is the part that keeps confusing me. You seem to think if installing were just easier, people would install more stuff (probably true), but I think the real limiting factor is getting the stuff properly packaged. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcement: One Click Installer
On Tuesday 07 August 2007 18:23, Krzysztof Lichota wrote: > Scott Kitterman napisał(a): > > OK, so for a Debian system, where do the.debs come from that One Click is > > needed for? > > The debs are already in repositories. It is about giving users easy > access to them. > > > This is the part that keeps confusing me. You seem to think if > > installing were just easier, people would install more stuff (probably > > true), but I think the real limiting factor is getting the stuff properly > > packaged. > > Try reading forum posts or the Scribus page I have mentioned > (http://www.scribus.net/index.php?name=Sections&req=viewarticle&artid=4&pag >e=1). They are full of descriptions how to add repository, how to add key, > etc. Repeated all over again. And in many cases they go to most common > denominator (modifying /etc/apt/sources.list and using apt-key in > console), because if they describe one application (like Synaptic), then > user might be using different (like Adept). > > Now imagine you are user who wants to install application. And he must > take so many difficult steps to achieve simple goal - installing > application. > > Or you are an application author which can either depend on his users to > know how to add repository, or he can create description how to do it > once again. > > This is the problem I am trying to solve. OK. That's a different problem then it sounded to me like you were trying to solve. That one is, I think, rather more reasonable. When you talk to me here about all the wonderful RPMs out there, it sounds to me like you're trying to re-invent alien, not make it easier to find and install packages for the distribution's packaging system. I'll note that another option is for said application author to work with distributions to get their application into the official/tested repository. I'll also note that in most cases I've run across when someone brings their package to Ubuntu, it is not initially up to Ubuntu packaging quality standards. In my opinion, moving outside of the distribution's package repository adds risk that should not be too thoroughly hidden from the user. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Announcement: One Click Installer - What I need as a third party APT repository maintainer
On Mon, 2007-08-06 at 19:01 +0200, Krzysztof Lichota wrote: > So, here is my shot at solving this problem - One Click Installer > (http://code.google.com/p/one-click-installer/). > > The idea is similar to this implemented in > https://wiki.ubuntu.com/ThirdPartyApt, but with broader scope > (supporting all distributions, not only Debian-based) and more features. > On Wed, 2007-08-08 at 14:07 -0500, Jerome Haltom wrote: > I agree with all of this. Except that I think what MS does is "just > fine.", and I've love to provide that ability for Ubuntu, and Ubuntu > alone. And so I will. Hence why I wrote wiki.ubuntu.com/ThirdPartyApt, > and am just now getting motivated to finish it (after this > conversation.) Right now, approximately 70 thousand people use the Winehq APT repository to keep an updated Wine package. Every one of them had to follow the instructions here: http://www.winehq.org/site/download-deb Simply put, these instructions suck. Google has GUI instructions for their repository, and those also suck: http://www.google.com/linuxrepositories/apt.html Both are as simple as we can make them, and they are inordinately frightening to new users. Pasting arcane shell commands as root into a terminal is not easy to use; neither is the 7 step graphical process Google gives. This is not fixable by the apt:// protocol, as that is (properly) not designed to encompass adding a new repository but instead install software from existing repositories. I, as an upstream ISV with my own third party repository, need it to be easy for the user to use my software. It should be so easy that I don't even need to give instructions - just a link to a single file that they can double click on. A user should be able to download a standard repository file, double click it, be informed about what packages and repository it's going to install, enter their password, and then be done. >From what I can tell, this is going to be handled exactly by Third Party Apt, and I hope it can be finished in time for Gutsy. Will One Click Installer also do this, perhaps embedding the internals of Third Party Apt on Ubuntu systems? Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: OEM installer script, multi-use?
Anthony Yarusso wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Phillip Lougher wrote: >> Anthony Yarusso wrote: >> >>> I was wondering if someone who helped develop the OEM install >>> option (or is familiar with it) knows whether it can be re-used. >>> ie, if you're leasing machines, can you send it out to a client, >>> get it back after a while and just run the script again to remove >>> the old user and set it up for the next one to put in their >>> preferences? >> Personally I would consider this too much of a security risk, >> personal or business sensitive data doesn't necessarily get removed >> once files are deleted. I would wipe or shred (both Linux >> commands) the disk before reuse. >> >> Phillip >> >> >> > Would it be possible to get shred options included in the script for > this sort of use? I think using wipe or shred on a drive would probably be a little over kill. dd zeros to the drive and then format would likely be enough to make the data prohibitively expensive to recover. This is of course depending on the data that was on the drive to begin with. For instance, I remember reading somewhere that the CIA destroys their hard drives in acid baths. The important part is to make recovery more expensive than the data is worth. As for the original question, I would say that it is going to be more trouble than its worth. I would much rather create a drive image with dd and then dd it back to the drive after every return. This would solve the above problem and you could likely create a network boot setup that did it automatically with a little work. Aka you would just plug the returning machine into a specialized network that would do all the needed stuff automatically. Btw, I'm not an ubuntu developer and I didn't help develop the oem installer, but I have had my head in the installer for other purposes. Someone may know a way of doing what you want, but I don't think it would be worth it either way. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: ML for ubuntu+1
On Saturday 18 August 2007 16:50, Chris Warburton wrote: > I enjoy trying to solve problems like these mentally, that's where the > Ideastorm thought came from is all. The one to work on I think is getting more actual development done. I don't think we lack for good ideas. I think we lack for people standing up and doing the work. Before you start moaning about employees can be told what to do (the usual response I get to this sort of point), most developers are not paid developers (myself for one). You can't order volunteers around. The paid devs are (and should be) focused on stuff that helps Canonical attract the customer base that buys support contracts. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: ML for ubuntu+1
On Saturday 18 August 2007 17:18, Chris Warburton wrote: > On Sat, 2007-08-18 at 17:01 -0400, Scott Kitterman wrote: > > On Saturday 18 August 2007 16:50, Chris Warburton wrote: > > > I enjoy trying to solve problems like these mentally, that's where the > > > Ideastorm thought came from is all. > > > > The one to work on I think is getting more actual development done. I > > don't think we lack for good ideas. I think we lack for people standing > > up and doing the work. > > > > Before you start moaning about employees can be told what to do (the > > usual response I get to this sort of point), most developers are not paid > > developers (myself for one). You can't order volunteers around. The > > paid devs are (and should be) focused on stuff that helps Canonical > > attract the customer base that buys support contracts. > > > > Scott K > > I know this. I'm doing some programming right now, but still only small > personal stuff because I've only just started to learn (I don't want to > break Ubuntu trough my incompetance). I started to learn how to program > precisely because I want to help out, and I also know that there's no > other way to get any of my ideas expressed. > > We're not all ungrateful > I-use-Ubuntu-because-I-can't-be-bothered-to-pirate-Windows people > y'know :) > > Cheers, > Chris > > PS: Don't take that in a bad way, I just felt a bit peeved that I've > spent all day in front of an IDE only to be told I should be doing some > development :) Understand, but that wasn't my point. I was trying to say rather than trying to figure out how to organize new ideas better, I think it would be more generally useful to spend time figuring out how to get more people developing. Thanks for diving in and starting to learn. You can also dive in and work on packaging at #ubuntu-motu (you do not need to be a programmer to learn how to help out with packaging). Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Fwd: Join the Debian Python Applications Packaging Team
Forwarded FYI for those who have Python applications they'd like to try and get into Debian. I've worked with the people from Debian Python Modules Team that are setting this team up and they are very open to contribution from Ubuntu. Scott K -- Forwarded Message -- Subject: Join the Python Applications Packaging Team Date: Sunday 26 August 2007 14:54 From: Piotr Ożarowski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hi, Do you need help with your Python application package but DPMT guys don't want to inject it in their repo because it's not a module? Do you have problems with finding sponsor due to this new nasty Debian Python Policy? I have something for you: new, shiny: *Python Applications Packaging Team* Interested? Read [1] or join us on #debian-python channel (OFTC network) [1] http://python-apps.alioth.debian.org/policy.html -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: new packages freeze policy
On Thu, 2007-08-30 at 19:01 -0400, Cory K. wrote: > > Sebastien Bacher wrote: > > hi, > > The archive admin members quickly discussed this and the packages > > uploaded before the freeze will be reviewed (no need of an uvf > > exception) for this cycle. Soren has updated the wiki to clarify that > > the packages should be uploaded some time before the freezes and that > > the archive team can take some extra days to process those > > > > > > Sebastien Bacher > > > This is indeed great news for this cycle, but... > > "packages should be uploaded some time before the freezes" > > If thats going to be the policy, whats the point of the freeze date? > Maybe moving the date up would be better? "some time before the freezes" > is rather vague for people trying to work with the proper deadlines. > > -Cory K (Ubuntu Studio lead) On this note, I got completely confused by the deadline. I read that the upstream version freeze deadline was August 30th, so I planned to upload my packages on the 30th. As it turns out, the deadline is at the stroke of midnight, UTC. When my boss tells me "This needs to be done by Friday," I generally don't interpret that as "I need this on my desk before midnight on Thursday." In other words, my package (Wine) is a day late and I'd like it reviewed anyway. Although, Wine has gotten about 3 UVF exceptions for the past three releases, so I'm not particularly worried. It's in REVU now anyway. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Non-"critical" bug fixes/new hardware drivers in stable releases?
On Friday 31 August 2007 20:27, Aaron Whitehouse wrote: > Tim, > > > While I can see the > > merit of keeping changes to "stable" to a minimum, it seems like the > > existing policy of Ubuntu (and many distributions - I'm not blaming > > Ubuntu in particular) is leaving many users out in the cold with regards > > to their issues until the next release. > > Backporting changes is risky. Ubuntu makes the decision that security > fixes are worth the risk of backporting. If you are talking about > changes that are available in later releases, then the affected users > are able to upgrade. In my opinion, it is more important that we don't > break the machines of people for whom everything is currently fine. > > I would love to see Ubuntu backport all new features to past versions, > but that would leave little point in having releases at all. It would > make it nearly impossible to check quality as the system would be in > continual flux. In order to backport non-critical/security updates, we > would need people testing those updates - people who could be working > to make the next releases better. With limited resources, I think > system stability on past versions would suffer. > This is what we have *-backports for. Each package gets at least minimal testing before it's approved for packporting. I don't recommend activating the backports repository for your release and installing everything, but for selected packages it can be very useful. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: new packages freeze policy
On Fri, 2007-08-31 at 23:00 +0200, Michael Bienia wrote: > On 2007-08-31 00:12:41 -0700, Scott Ritchie wrote: > > On this note, I got completely confused by the deadline. I read that > > the upstream version freeze deadline was August 30th, so I planned to > > upload my packages on the 30th. > > I guess you mixed up UpstreamVersionFreeze and NewPackage for Universe > Freeze. The first was already on August 16th. Could someone remind me the purpose of this distinction? Why should newer, buggier packages be given a later freeze time? Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: new packages freeze policy
On Saturday 08 September 2007 00:40, Scott Ritchie wrote: > On Fri, 2007-08-31 at 23:00 +0200, Michael Bienia wrote: > > On 2007-08-31 00:12:41 -0700, Scott Ritchie wrote: > > > On this note, I got completely confused by the deadline. I read that > > > the upstream version freeze deadline was August 30th, so I planned to > > > upload my packages on the 30th. > > > > I guess you mixed up UpstreamVersionFreeze and NewPackage for Universe > > Freeze. The first was already on August 16th. > > Could someone remind me the purpose of this distinction? Why should > newer, buggier packages be given a later freeze time? > Since they are new to Ubuntu, there is no risk of regression from a previous release. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: new packages freeze policy
On Sat, 2007-09-08 at 00:50 -0400, Scott Kitterman wrote: > On Saturday 08 September 2007 00:40, Scott Ritchie wrote: > > On Fri, 2007-08-31 at 23:00 +0200, Michael Bienia wrote: > > > On 2007-08-31 00:12:41 -0700, Scott Ritchie wrote: > > > > On this note, I got completely confused by the deadline. I read that > > > > the upstream version freeze deadline was August 30th, so I planned to > > > > upload my packages on the 30th. > > > > > > I guess you mixed up UpstreamVersionFreeze and NewPackage for Universe > > > Freeze. The first was already on August 16th. > > > > Could someone remind me the purpose of this distinction? Why should > > newer, buggier packages be given a later freeze time? > > > Since they are new to Ubuntu, there is no risk of regression from a previous > release. > > Scott K > If preventing regressions is the concern, then perhaps we should make that clearer in the UVF exception process. Most UVFe applications I've seen seem to center around how much better or important the new package is, rather than a reduced chance of regressions. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
A week of games: Chess is too hard and Gnometris is really bad
I moved apartments last week, and could not get online until now. I had just installed Gutsy before moving, and without internet there was little to entertain me other than the default games that ship with Ubuntu. I played every game, some of them a lot, and when something annoyed me I wrote it down. Most of them work just fine. We can't expect every game to be fun for everyone, and fortunately every game we have should at least appeal to someone. Two of the games, however, bother me: Chess and Gnometris. Chess works fairly well. The trouble is that we only ship one AI, and even in easy mode it requires a solid amount of thinking for me to beat. This is too difficult; we need a chess difficulty that an 8 year old child can beat. See https://bugs.launchpad.net/ubuntu/+source/gnome-chess/+bug/138570 Chess also has serious usability issues. Rather than a new game with sensible settings, by default the chess window loads the previous game played. If I wanted the old game I closed I would load it myself. Worse still, there is no obvious way to close it (instead you must click Game->end game), and starting a new game unexpectedly shrinks the board and opens a tab. We should seriously consider eliminating the tab functionality from chess altogether. Chess isn't like Firefox; a user who wants two separate games can very easily open the program twice, and unlike web browsing almost no one will want to rapidly hop between them. See https://bugs.launchpad.net/ubuntu/+bug/138574 Gnometris, however, has more serious issues.. The controls are very unresponsive (bug # link) around level 3, making even basic play extremely frustrating. Nothing is more aggravating in Tetris than letting go of the move key and watching your piece keep flying across the screen beyond your control. See https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/138586 The interface has serious problems too. The starting level, number of pre-filled rows, and density of blocks in a pre-filled row are all nonfunctional. They snap back to 0 immediately. The default background is also the blue Gnome foot, contrasting sharply with the default theme. We'll need to remember to replace it with a nice Ubuntu logo before release. See https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/138597 Scoring is also completely broken. The scoreboard doesn't track the number of lines you remove, and unlike every other Tetris implementation there are no bonus points for dropping a tile early. Worse still, the points make no sense. Scoring 4 at once is 7.5 times as valuable as scoring 4 lines separately, yet both advance the level the same. Combine the unresponsive controls with this scoring system, and the game degenerates into little more than trying to line up Tetrises until you get to level 5 when it becomes impossible to place a piece where you want it. See https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/138603 Chess is quite playable, however the situation with Gnometris is so bad I'm going to recommend we don't include it by default unless these issues get fixed. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: python-cjson is on Debian but not on Ubuntu
On Mon, 10 Sep 2007 11:39:53 +0530 Shriramana Sharma <[EMAIL PROTECTED]> wrote: >Dear Python developers, > >python-cjson is available on Debian Lenny/Sid but still not there in the >Ubuntu repos. > >Please see: > >http://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=names&keywords=cjson >http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=cjson&searchon=names&subword=1&version=all&release=all > >When other json modules for python are available in Ubuntu: > >http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=json&searchon=names&subword=1&version=all&release=all > >is there any reason that python-cjson is not available? It's a recent >addition to Debian itself (2007-Aug-14) so it may have been overlooked >but it's a must-include, IMHO. That was past the point where automatic syncing from Debian happened and no one requested it be done manually. We are now close to two weeks past the New Package Freeze for Gutsy, and so inclusion in Gutsy (even if an exception was requested) is unlikely. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: python-cjson is on Debian but not on Ubuntu
On Monday 10 September 2007 11:23, Shriramana Sharma wrote: > Scott Kitterman wrote: > > That was past the point where automatic syncing from Debian happened and > > no one requested it be done manually. We are now close to two weeks past > > the New Package Freeze for Gutsy, and so inclusion in Gutsy (even if an > > exception was requested) is unlikely. > > Right. Do I have to do anything to get it included in Hardy? Do *all* > Debian packages get synced to Ubuntu or do you people pick and select? > > Shriramana Sharma. I believe that generally new packages get synced automatically, but I'm not 100% certain. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: LTS to LTS upgrade path
On Friday 14 September 2007 22:43, Onno Benschop wrote: > Now I understand that resources are limited and that we're a little way > away from needing this functionality, but if I look back at the gap > between Edgy and Feisty, it was all over way too soon, so I suspect that > it would be useful to start some discussion about this. > > I'm happy to stick up my hand to help. A good start would be someone fixing this bug: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/104038 Upgrade to feisty causes loss of TTYs due to incorrect file mangling I recently did an experimental Dapper --> Gutsy upgrade with this sort of question in mind. It was painful, but except for this TTY problem I ended up with a functional system. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: update-db cron job: solving a long-standing issue
On Sat, 15 Sep 2007 17:53:11 +0200 Soren Hansen <[EMAIL PROTECTED]> wrote: >On Sat, Sep 15, 2007 at 04:54:57PM +0200, Milan wrote: >> We can also think (and this is my opinion ;-) ) that the locate >> command is only used by advanced users that now how to install slocate >> in two minutes, and thus that we don't need to install it by default. > >I agree with this. Heck, I consider myself a pretty advanced user, and >the number of times I've used locate in my life can be counted on one >hand (with enough fingers to spare to pick my nose and do a bit of >typing). I realise the benifits of it, but I've just never gotten used >to it, and it's really not very easily discoverable. If one were to find >mention of it in a magazine or on IRC or whatever, it /is/ only a quick >apt-get away. IMO, nuke it. IME the utility is never really used, and >the daily(?) updatedb run is annoying and confusing to users who haven't >asked for it. I use locate regularly on desktops and servers. If there are locate variants that update synchronously rather than once a day, I say looking into that is the best answer. It would both eliminate the daily cron job system slowdown and the primary limitation of locate (that it doesn't know about files added since the cron job has run). For experienced administrators I think the absence of locate would be quite suprising. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
The latest amd64 nightly desktop ISO is 730 megs
The latest nightly ISO for AMD64 is too large to burn - even with overburning enabled. The end result is that I can't test it. Is this a simple bug, or are nightly images allowed to get too large? Did something large creep in recently? Either way, it seems like having a burnable CD image should be a priority, even on a day to day basis. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The latest amd64 nightly desktop ISO is 730 megs
Murat Gunes wrote: > Scott Ritchie wrote: >> The latest nightly ISO for AMD64 is too large to burn - even with >> overburning enabled. The end result is that I can't test it. >> >> Is this a simple bug, or are nightly images allowed to get too large? >> Did something large creep in recently? >> >> Either way, it seems like having a burnable CD image should be a >> priority, even on a day to day basis. >> >> Thanks, >> Scott Ritchie > > The daily images get built automatically and no effort is made to make > them fit on a CD; such an effort is only made for the milestones. > > m. > > Perhaps the build script should throw up a warning somewhere. Otherwise there's almost no point to having them. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The latest amd64 nightly desktop ISO is 730 megs
Murat Gunes wrote: > Bryce wrote: >> That really does not make any sense if thats the case. What is the >> point in making daily images available for testing if know one is going >> to be able to use them? > > Not many daily images end up oversized. If it were a substantial > percentage of all images, you'd have a point. With the current state of > things, people can wait a day, or two at worst, or use the image from a > day or two before (I think jidgo is not an option with the live CDs, but > should be usable with the alternate CD; I'd be happy if someone could > confirm this). It's not realistic to expect all uploads to be concerted > to such an extent as to be able to meet a certain maximum size on a > daily basis. > > Scott Ritchie wrote: >> Perhaps the build script should throw up a warning somewhere. Otherwise >> there's almost no point to having them. > > I think it creates files that end with .OVERSIZED corresponding to the > image that ends up being oversized. > > m. > > In this case it didn't - I didn't even come across a warning. Honestly it would be best if no image was made, rather than an unburnable one. Nothing wrong with skipping a few days when the nightly isn't buildable. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The latest amd64 nightly desktop ISO is 730 megs
Murat Gunes wrote: > Scott Ritchie wrote: >> In this case it didn't - I didn't even come across a warning. > > In http://cdimage.ubuntu.com/daily-live/20070914/ I can clearly see that > there are two files that end with .OVERSIZED; I guess the capitalization > is to draw attention to the fact. You could also check for the presence > of the file with a script to determine whether a particular day's image > is oversized or not. > > You may want to file a bug in the ubuntu-cdimage product at Launchpad if > you feel the warning should be in some other form and/or made more explicit. > Fair enough. Done: https://bugs.launchpad.net/ubuntu-cdimage/+bug/140049 >> Honestly it would be best if no image was made, rather than an unburnable >> one. >> Nothing wrong with skipping a few days when the nightly isn't buildable. > > Even though a VM isn't the ideal way to test, it's usable for many > testing cases, and the fact that oversized images are still usable in a > VM should be enough of a reason to keep building them. > > m. > This is a good point. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: should people.ubuntu.com be people.canonical.com
Jordan Mantha wrote: > Secondly, I think we would increase collaboration and development > tools if the community developers were allowed to have access to > people.ubuntu.com. The Canonical devs already use that space quite > extensively (making moving it definitely non-ideal). The MOTU have > lost their machine (tiber) in the compromise and for some time scripts > have been hosted in various places. Launchpad can certainly be used > for hosting bzr and packages now, but things like task lists, bug > reports, and helpful scripts/tools don't have a place on Launchpad. > Agreed. It's pretty silly that we host REVU on a completely separate domain, for example. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: python-cjson is on Debian but not on Ubuntu
On Monday 17 September 2007 14:53, Kjeldgaard Morten wrote: > Another missing package in Gutsy is the emboss suite, even though it > is in Sid: > > http://packages.debian.org/sid/emboss It wasn't in Sid when the auto-sync was turned off. It'll be automatically sync'ed for Hardy. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
More libraries needed in ia32-libs for Wine
I've uncovered a few bugs in the Wine package for AMD 64 that are the result of a few 32 bit libraries not being included at build time. Among those we lack 32 bit version of in any package: libssl (for both libssl and libcrypto) libjack And a few others related to translation. Wine won't work fully without these libs in some 32 bit form. What I want to know is the best way to proceed from here. It seems like there are several options: Option 1: Patch ia32-libs to include all the missing libraries. The main upshot of this approach is that it will certainly work if implemented, and the Wine package won't even need to be modified. The main downside is that the ia32-libs package will get even more bloated, if it's even done at all: a look at some launchpad bugs shows ia32-libs has been missing a few libraries for several releases now. We also introduce the possibility of regressions to packages expecting there to NOT be certain libs in /usr/lib32 (say, if a build script assumes only one libssl). Option 2: Create a new ia32-libs-wine package that includes the needed libraries. This is similar to the approach taken with openoffice in the past, and it allows us to create a very specific package that only Wine needs. The downside is that we add yet another package, and it will get weirdly named if a non-Wine package begins to depend on it. However, we can keep ia32-libs-wine in universe. Thoughts? Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
LP 1.1.9 considered harmful (was Re: That need to close bugs?)
On Saturday 22 September 2007 05:38, Matthew Garrett wrote: > On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote: > > I agree entirely. What drives *me* batty in turn is when people take a > > confirmed, complete report, ask why it hasn't been fixed yet, and close > > it as invalid because obviously something that's been around for a > > couple of releases can't be relevant any more. Or when people reject > > perfectly valid and complete wishlist bugs (note that it usually takes a > > lot less for a wishlist bug to be complete) because they should be > > specifications (they shouldn't, in most cases) or just because they're > > wishlist. As a developer, I wish I didn't have to spend time checking my > > bug mail just to make sure that well-intentioned but mistaken triagers > > aren't taking items off my to-do list that I want to stay there. > > Something appears to have flagged all inactive bugs as invalid. Apart > from generating a ridiculous quantity of email for no obviously good > reason, a pile of perfectly valid wishlist bugs or issues that require > further work in the rest of the distribution first have suddenly closed. > Who on earth thought that this was a good idea? > This is apparently by design (at least in part). The theory (and I don't agree with it) appears to have been that if information was asked for from a reporter and it was not gotten for some period of time, then an incomplete bug could be marked invalid. Even if the theory was valid, the current implementation appears to be marking all bugs that have been in an incomplete state for 60 days as invalid independent of if there has been activity on the bug. See: https://bugs.launchpad.net/bugs/141652 for details. I took about an hour to go through the stack of bugmail I got about this and I did not find a single bug that should have been closed (in my opinion) that could not have been closed by marking it Fix Released with the bug it's a dupe of was marked. 60 days is to short. Even if we set a time, there are classes of bugs (such as crashes) that even if incomplete are not invalid (a crash bug is always a bug). I don't think bugs should get marked invalid except manually. In my opinion, there have been a number of feature additions to LP recently that were not well thought through. A few additional examples: 1. Allowing PPA uploads to auto close bugs. (I know this one is fixed now, but it boggles my mind to think how it could have been overlooked) 2 Including a backports release as the current Ubuntu release on the new package page (I'm not a fan of the new page, but that aside, the concept is not well thought through). 3. Including changelog fragments on the new package page (easy to find incomplete information can be actively dangerous). I know that the LP developers are working very hard to provide a useful tool. This is not meant to be an attack on their efforts or their competence. The real problem (as it appears to me as an outsider) is a lack of process focus on good up front design and an excessive faith in "well catch it in the beta" to surface flaws. I promised sabdfl on IRC that I wouldn't exaggerate about problems, so I went back through the 1.1.9 release announcement to see if there were any changes that had affected me (most don't) that I liked. I came up with: * When Launchpad is offline, you will now be able to see if it is offline for maintenance or offline unexpectedly. Finally, I used to be able to add a link to an upstream bug. I appear to have lost that ability for anything that's not "registered" in Launchpad. I'm not about to sit through registering every package I touch to do upstream bug linking. Scott K P.S. This is on an Ubuntu list and not an LP list because I think that this upgrade is bad for Ubuntu and am concerned about our future productivity if the trend continues. This is an Ubuntu issue. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: automatic dpkg --configure -a
Gianmarco Leone wrote: > Hi all, > I had a little idea that could be trivial to implement, and I don't see > any drawback in implementing it. When you interrupt a package manager > (apt-get or synaptic) you have to manually run "dpkg --configure -a" to > make thing clean again (you complete the installation/upgrade process of > the packages). My idea is to automatically run it at boot. If everything > is ok, it doesn't do anything, else he complete the broken process at > boot without the need to run manually the command in a terminal. USE > CASE: abnormal termination of dpkg causated by a power failure or a > discharged battery. > Ciao, > Gianmarco > This can also happen due to running out of disk space on the / partition. This is a very plausible scenario, and it's especially annoying since you can't run apt-get autoclean to free up disk space until you run dpkg --configure -a We may not want to wait for a reboot here. Just integrate it into the update manager if it detects dpkg --configure -a still needs to be run. Thanks, Scott Ritchie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing
On Thursday 27 September 2007 10:01, Milan wrote: > And how about using ReiserFS by default, or any other journaled > filesystem that doesn't require fsck to run regularly? I'm using > reiser3, and I hadn't noticed that fsck was run by default on startup > until a friend of mine installed Ubuntu with standard settings (i.e. > with ext3). > > >From Wikipedia: "ReiserFS is the default file system on the Slackware > > <http://en.wikipedia.org/wiki/Slackware>, Xandros > <http://en.wikipedia.org/wiki/Xandros>, Yoper > <http://en.wikipedia.org/wiki/YOPER>, Linspire > <http://en.wikipedia.org/wiki/Linspire>, GoboLinux > <http://en.wikipedia.org/wiki/GoboLinux>, Kurumin Linux > <http://en.wikipedia.org/wiki/Kurumin_Linux>, FTOSX and Libranet > <http://en.wikipedia.org/wiki/Libranet> Linux distributions > <http://en.wikipedia.org/wiki/Linux_distribution>. ReiserFS was the > default file system in Novell <http://en.wikipedia.org/wiki/Novell>'s > SUSE Linux Enterprise until Novell decided to move to ext3 > <http://en.wikipedia.org/wiki/Ext3> on October 12 > <http://en.wikipedia.org/wiki/October_12>, 2006 > <http://en.wikipedia.org/wiki/2006>^ for future releases." > Why did Novell went back to ext3? ReiserFS is effectively unmaintained. I've switched from ReiserFS to Ext3 for my installs too. While it works well now, bitrot seems inevitable. Scott K Note: This has nothing to do with an legal issues the developers have. The Reiser devs have been focused on ResierFS4 for quite some time. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing
On Thu, 27 Sep 2007 16:17:43 -0400 Phillip Susi <[EMAIL PROTECTED]> wrote: >Scott Kitterman wrote: >> ReiserFS is effectively unmaintained. I've switched from ReiserFS to Ext3 for >> my installs too. While it works well now, bitrot seems inevitable. >> >> Scott K >> >> Note: This has nothing to do with an legal issues the developers have. The >> Reiser devs have been focused on ResierFS4 for quite some time. > >The point though, is still valid; reiserfs doesn't bother forcing a disk >check every n mounts, so why does ext3 still do this? I think these >days the kernel is bug free enough and hardware is generally reliable >enough that we can drop the forced fsck by default. > Dunno. I was just answering your "Why not ReiserFS?" question. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
*blocking* bugs in development versions (e.g. Gutsy).
How does one convey the message that a bug is severe? A recent update to HAL (0.5.9.1-1ubuntu9) in Gutsy won't install/upgrade due to errors and therefore it's dependents (and their defendants) won't install/upgrade I've been running Gutsy for weeks and this is the biggest bug I've run into (and of course we're now in the beta phase). I have to manually configure eth0 at every boot. I can no longer access external hard drives. I've reported this (as have others) and it's still "undecided"? Things that make you go humm.. -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: *blocking* bugs in development versions (e.g. Gutsy).
Dean Sas wrote: > Scott (angrykeyboarder) wrote: >> How does one convey the message that a bug is severe? > > Including a bug number in your mail would get more eyes looking at it. > > Thanks, > > Dean oops. :) https://bugs.launchpad.net/ubuntu/+source/hal/+bug/146741 ..which leads to... https://bugs.launchpad.net/ubuntu/+source/hwdb-client/+bug/147480 https://bugs.launchpad.net/ubuntu/+source/hal/+bug/147478 https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/146768 https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/146760 -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: *blocking* bugs in development versions (e.g. Gutsy).
Scott (angrykeyboarder) wrote: > Dean Sas wrote: >> Scott (angrykeyboarder) wrote: >>> How does one convey the message that a bug is severe? >> Including a bug number in your mail would get more eyes looking at it. >> >> Thanks, >> >> Dean > > oops. :) > > > > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/146741 > > ..which leads to... > > https://bugs.launchpad.net/ubuntu/+source/hwdb-client/+bug/147480 > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/147478 > https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/146768 > https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/146760 > Correction. I just filed a new bug. It in turn, is the cause of 146741 I'm surprised I'd not seen this bug before (I'm sure it's there but I somhow missed it so mine will probably end up as a dupe). But Just in case... https://bugs.launchpad.net/ubuntu/+source/hal/+bug/147963 -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug statuses
On Tuesday 02 October 2007 17:32, Emilio Pozuelo Monfort wrote: > Christian Robottom Reis wrote: > > - Fourth, would it help is Launchpad made it really easy for you to > > post the bug to SourceForge, perhaps opening the bug-filing page > > with all your details filled in and just waiting for you to > > submit? > > I think so. That would be really useful, since that would save a lot of > time (not that reporting a bug takes one hour, but when you report a > lot, then there's a big difference). This would have a big risk, though, > which is that there could be 'spam' in upstream's bug trackers, but this > could be avoided by only letting people in the Distribution Bug Contact > team to report bugs upstream using that method. > > Also, I'm sure Sebastien will thank you if you implement this to forward > bugs to bugzilla.gnome.org ;) > This all presumes that the reporter knows enough to: 1. Not kick Ubuntu specific package bugs upstream or to Debian. 2. Direct Debian packaging bugs to Debian. 3. And as a result only report real upstream bugs to the upstream. I agree that if this feature is to be offered, it ought to have some kind of restriction on it. Since anyone can sign up to be a bug contact for a package, I'm not sure that's the right thing to key on though. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Gutsy's HAL is "broken".
I *can't* be the only one with this problem.
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/147963
--
Scott
http://angrykeyboarder.com
©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Gutsy's HAL is "broken".
Scott James Remnant spake thusly: > On Tue, 2007-10-02 at 18:28 -0700, Scott (angrykeyboarder) wrote: > >> I *can't* be the only one with this problem. >> >> https://bugs.launchpad.net/ubuntu/+source/hal/+bug/147963 >> > It's entirely possible that you could be. :( > > Perhaps you could provide more information on the bug, e.g. output from > syslog, I browsed through the syslog and couldn't find anything that seemed relevant (but then maybe I did it wrong?). > what happens if you run HAL manually, etc. I'm not sure how to gather the needed output from syslog and I'm not really sure I understand how to run HAL manually. Let's see here... - $ sudo /etc/init.d/hal stop * Stopping Hardware abstraction layer hald [ OK ] $ sudo /etc/init.d/hal restart * Restarting Hardware abstraction layer hald $ - The response on both was immediate but you'll note the lack of an "OK" on the restart. OK, I'll try this.. - :~$ sudo /etc/init.d/hal stop * Stopping Hardware abstraction layer hald [ OK ] :~$ sudo /etc/init.d/hal start * Starting Hardware abstraction layer hald - It just hangs.. And now for the last of the commands I know of... - :~$ sudo /etc/init.d/hal stop * Stopping Hardware abstraction layer hald [ OK ] :~$ sudo /etc/init.d/hal force-reload * Restarting Hardware abstraction layer hald - Another quick response but no "OK" on the force-reload. So then.. - $ sudo dpkg --configure -a Setting up hal (0.5.9.1-6ubuntu1) ... * Reloading system message bus config... [ OK ] * Starting Hardware abstraction layer hald dpkg: error processing hal (--configure): subprocess post-installation script killed by signal (Interrupt) dpkg: dependency problems prevent configuration of gnome-mount: gnome-mount depends on hal; however: Package hal is not configured yet. dpkg: error processing gnome-mount (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of kubuntu-desktop: kubuntu-desktop depends on hal; however: Package hal is not configured yet. dpkg: error processing kubuntu-desktop (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of gnome-volume-manager: gnome-volume-manager depends on hal (>= 0.5.5.1); however: Package hal is not configured yet. gnome-volume-manager depends on gnome-mount; however: Package gnome-mount is not configured yet. dpkg: error processing gnome-volume-manager (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of xubuntu-desktop: xubuntu-desktop depends on gnome-mount; however: Package gnome-mount is not configured yet. xubuntu-desktop depends on hal; however: Package hal is not configured yet. dpkg: error processing xubuntu-desktop (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of update-notifier: update-notifier depends on hal; however: Package hal is not configured yet. dpkg: error processing update-notifier (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of xfce4-session: xfce4-session depends on hal; however: Package hal is not configured yet. dpkg: error processing xfce4-session (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of ubuntu-desktop: ubuntu-desktop depends on gnome-volume-manager; however: Package gnome-volume-manager is not configured yet. ubuntu-desktop depends on hal; however: Package hal is not configured yet. ubuntu-desktop depends on update-notifier; however: Package update-notifier is not configured yet. dpkg: error processing ubuntu-desktop (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of network-manager: network-manager depends on hal (>= 0.5.7.1); however: Package hal is not configured yet. dpkg: error processing network-manager (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of thunar-volman: thunar-volman depends on gnome-mount; however: Package gnome-mount is not configured yet. dpkg: error processing thunar-volman (--config
Re: Gutsy's HAL is "broken".
Caroline Ford spake thusly on 328153984 :: > On Thu, 2007-10-04 at 05:05 -0700, Scott (angrykeyboarder) wrote: > > This really belongs on the bug tracker not here. Pardon moi? I never said that > >> X Error: BadDevice, invalid or uninitialized input device 171 >> Major opcode: 149 >> Minor opcode: 3 >> Resource id: 0x0 > > What is this? X always seems to think I have a Wacom tablet. I think that's related to it's misjudgment. > Do you have any interesting hardware? All of it is utterly fascinating. -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
4 More days...
till the release of the most bug-ridden Ubuntu release yet (unless the devs go into overdrive in the next few days)! -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
Onno Benschop spake thusly: > On 15/10/07 07:31, Scott (angrykeyboarder) wrote: >> till the release of the most bug-ridden Ubuntu release yet (unless the >> devs go into overdrive in the next few days)! >> > > I have to say that I was quite offended by your statement. It's not > constructive in any way and it does not reflect the amount of effort, > both paid and unpaid, put in by the community. I'm infamous for opening mouth and inserting foot and I tend to fly off the handle (irrationally at times - hence my nickname). I don't deny that a lot of people have put a lot of effort into this release as they always do. Perhaps the problem isn;'t so much the bugs themselves but the responses (or lack thereof) from devs to the bugs. And I want to see Ubuntu succeed. I "play" with several distros and any given time (in virtual machines) but Ubuntu is my base system. Why, because despite it's shortcomings i still best meets my needs. And I'm generally impressed with the community (despite my perceived statements to the contrary). > > If you're frustrated with the development process perhaps you should > find another way to contribute to its success. I've been running Gutsy for a little over two months now. In part because I wanted to help out. But it's quite disheartening to file bug reports (some of which are seemly serious) only to find that they don't merit any kind of response other than "undecided" for days (or perhaps weeks) on end. I realize that most bugs are rather trivial in the big scheme of things, but bugs that affect everyday operation of the system (or of widely regularly used applications - e.g. those in main) are something else). And in case anyone was wondering.. No, I'm not just speaking of bug reports I've filed (or added to). I've browsed through a number of others and found they garnered little or no response other than "undecided" as well. I get more constructive response on my bug reports from devs to on this mailing list than I do in the bug reports themselves. What's wrong with this picture? -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
John Dong spake thusly on 317253208 :: > This is not very constructive. All of us here put our heart and effort > into the distro and comments like this don't help. Exactly what things > are bug-ridden that need attention? It's one thing to raise awareness of > last-minute important bugs, but this seems to be nothing more than > flamebait > It wasn't meant as flamebait. It was my foolish way of venting pent-up frustration (see my replies to others in this thread). -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
Matthew Garrett spake thusly: > With the exception of the Thunderbird and timidity issues (and I can't > reproduce the timidity one here at all), every bug you've responded to > in gutsy appears to be down to your issue with Hal. And, judging by the > log there, your system was entirely broken: > > 03:13:09.373 [W] ids.c:294: Couldn't stat pci.ids file > '/usr/share/misc/pci.ids', errno=13: Permission denied > 03:13:09.373 [W] ids.c:515: Couldn't stat usb.ids file > '/usr/share/misc/usb.ids', errno=13: Permission denied > 03:13:09.373 [E] osspec.c:310: Unable to inotify_add_watch() for > '/usr/share/hal/fdi/preprobe': Permission denied > > indicates either filesystem corruption or that something has heavily > screwed with the permissions. It certainly doesn't look anything like a > hal bug. What are you actually complaining about? I'm a lowly user who only knows somewhat more than the average Joe, but is pretty much in the dark about a lot of this stuff. In fact, I can read descriptions of programs like hal and dbus and still not fully grasp their purpose. Bearing that in mind, there are plenty out there who know a fraction of what I do. They are the ones Ubuntu is catering to by all the (very nice and convenient I might add) apps that give little reason for new users to ever open a terminal. But I digress All of this stuff you quoted from my report is utter gibberish to me. I do understand "permission denied" and found that quite odd and that alone told me that something wasn't right. I had no way of knowing what the problem was other than it seemed related to HAL because only when attempting to upgrade to a new version of HAL did that problem rear it's head. If it was a filesystem corruption or messed up permissions, then it only seemed to be affecting the installation of HAL. You know how many updates there are on a given day. Well virtually all of them went without a hitch (they now number in the hundreds I'm sure). The ones that didn't were generally due to a conflict in a package that shared the same file with other (something I've noticed in a number of KDE apps from time to time over the past few years). There are easy workarounds for those (although I wouldn't have known that a few years ago). So up until your response here I had no reason to believe it was anything but a corrupt installation of HAL. And the only thing that could have caused that based on my own behavior is a corrupt package or packages or maybe a broken install or corrupt download or something similar. I had no way of knowing if the problem was on your end, my end or en route... Now... I thank you for the helpful information you have given me today but I have to ask... Why (as of this writing) is this not mentioned in the bug itself? Wouldn't that have been the place it should have gone to begin with? Since you're a developer and you took a look at my bug and came to that conclusion, why not add that information to the bug rather than here? This is one example of how poor communication with regard to bug reports can be a big cause of frustration. And the bug in question was only "bolstered" by the "me too" comments that followed. As well as a very similar bug I happened upon earlier today when I was browsing HAL-related bugs. From all appearances (as of this writing) that bug report is STILL "undecided". Isn't that a tad odd? As far as the Thunderbird issue was concerned, I know it's minor in the scheme of things and therefore the bug will probably be in the same state 3 months from now as it is today... Frustrating? Yes. Important in the big scheme of things? No, not really, but it was sort of like throwing gasoline on a (my) fire at this point. As luck would have it, Feisty missed the cutoff for Thunderbird 2.0 by a matter of a few weeks, so I'd been looking forward to using Ubuntu's version once again (I used Mozilla's instead - why wait 5 months when you don't have to). So it looks like I'll be back to square one there. Again, minor in the big scheme of things, but not to this user. Oh and as far as timidity, goes - definitely minor. I barely remember even filing the bug. I do try to help out when I can by filling bugs though so that's why it was there. At the time it was a problem. I've not even reinstalled it when I did a clean install recently. There are several other annoying bugs out there that I've just not had the time or patience to file (or add to). But they are more fuel to the fire. And why would Ubuntu or Kubuntu include a default install of a desktop search application that seems to do more harm that good? I've yet to hear anybody sing the praises of Beagle/Kerry (or strigi as is now the case of Kubuntu - they went from one bad o
Re: 4 More days...
Sarah Hobbs spake thusly : > Oh, just let me wave my magic wand, and fix it all! Good luck. There are scads of bugs with "Undecided" status on them. You've got your work cut out for you even with that magic wand. > Yay for unproductive mails! My first "productive" email here was completely ignored. > Sometimes i wish even ubuntu-devel-discuss > was moderated, so we don't get utterly useless mails like this. Yes, well you can't always get what you want and neither can I. :) -- Scott http://angrykeyboarder.com ©2007 angrykeyboarder™ & Elmer Fudd. All Wites Wesewved -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: 4 More days...
On Monday 15 October 2007 23:10, Scott (angrykeyboarder) wrote: > Sarah Hobbs spake thusly : > > Yay for unproductive mails! > > My first "productive" email here was completely ignored. > That's a step up from this one. You're unignored, but certainly not making progress on getting stuff fixed. I will tell you that, for me personally, your mail has made me significantly less interested in looking at your bugs. I've got enough pleasant things to spend my free time on that I really don't need this sort of thing. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 06:02, João Pinto wrote: > Hello , > getdeb packages requirements do not meet ubuntu backports requirements, > ubuntu backports are based on versions available on the development > version, getdeb packages are based on the latest upstream version, some of > the software is not even available at the development version. This is largely because you choose to work outside Ubuntu. If you put your efforts into updating the packages in the development version, then many, if not most, of the packages you provide could be done through backports. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 10:22, João Pinto wrote: top posting reformatted > 2007/10/16, Scott Kitterman <[EMAIL PROTECTED]>: > > On Tuesday 16 October 2007 06:02, João Pinto wrote: > > > Hello , > > > getdeb packages requirements do not meet ubuntu backports > > > requirements, ubuntu backports are based on versions available on the > > > development version, getdeb packages are based on the latest upstream > > > version, some > > > > of > > > > > the software is not even available at the development version. > > > > This is largely because you choose to work outside Ubuntu. If you put > > your > > efforts into updating the packages in the development version, then many, > > if > > not most, of the packages you provide could be done through backports. > > > > Scott K > Scott, > besides myself there other debian/ubuntu contributors which also contribute > to getdeb, when they do it for an official project you classify them as > insiders, and on other project, outsiders ? > What part of our work is not available to the Ubuntu community from both > users an developer's perspective ? > How does creating a project with a different methodology, goals, and > resources make us "outside" Ubuntu ? > As per your comment there is an "Ubuntu inside" certification that we can > get somewhere, how do I get such certification ? > > I do believe that when doing volunteer work we can do whatever we like to > do, I find very odd to receive negative comments, not because we are doing > something wrong, but because we are not doing ONLY what some people believe > is right. > > Do you have any arguments against the project besides the "outsiders" tag ? > I do expect to get those so that we can better identify improvement > opportunities. Ubuntu has official repositories. Getdeb isn't one of them. I don't know what can be clearer than that. If you want to be "Official" talk to the Ubuntu Tech Board. That's what Backports did. You provide packages that are newer/not in the official repositories. With the exception of packages that are legally questionable for the official repositories, why? If you would focus your work towards the actual Ubuntu repositories, more people would benifit. It's not that I think what you are doing it wrong, but that much of it is duplicative and it'd be better for all if your efforts were more in the official repositories. That said, you are free to volunteer however you see best. To me it seems like your wasting a lot of effort, but clearly you have an agenda that I don't understand. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 11:51, João Pinto wrote: fixed top posting (again). > > Ubuntu has official repositories. Getdeb isn't one of them. I don't > > know what can be clearer than that. If you want to be "Official" talk to > > the Ubuntu Tech Board. That's what Backports did. > > > > You provide packages that are newer/not in the official repositories. > > With the exception of packages that are legally questionable > > for the official repositories, why? > > > > If you would focus your work towards the actual Ubuntu repositories, more > > people would benifit. It's not that I think what you are doing it wrong, > > but > > that much of it is duplicative and it'd be better for all if your efforts > > were more in the official repositories. That said, you are free to > > volunteer however you see best. To me it seems like your wasting a lot > > of effort, but clearly you have an agenda that I don't understand. > > > > Scott K > > > Hello, > did you missed the part that I told we do not provide a repository and the > reasons for such limitation ? > What do official repositories have to do with a non repository based > software distribution ? > What have official repositories to do with "outside of Ubuntu" ? Ubuntu is > composed by a large community which works on a broad range of areas, it is > not just about official repositories. Sure. There is an Ubuntu community. In my opinion you are working outside of it, but to each his owne. > We provide packages which are new/not in the official repositories, > because, we want them to become available for the users. If your question, > is, why don't we follow the MOTU processes to make them available, then we > go into another subject which is not about getdeb. Neither would I be able > to represent all the individuals which create/submit/request packages to > getdeb, some of them do also parallel work, they are submitting both to > getdeb and to the official processes, on getdeb it is likely that they will > become available in 1 week, the same package, following official processes, > may take several weeks, or months, please note that our QA requirements are > not as strict(good) as the Debian/Ubuntu packages. For updates to existing packages when the repositories are open for it, the backports timeline can be similar if users are motivated. You've said before that I misinterpret your statements when it sounds to me like you say you unwilling to package things properly, but that's what I'm hearing again. > Again my question, which people benefits from Ubuntu official repositories > and does not from GetDeb ? The -updates/-security repositories are enabled by default and -backports is there to be easily enabled if someone wants them. GetDeb is an entirely separate thing that people have to go look for. I don't understand why this is so confusing. > We are not doing duplicate work, we use a lot of Debian/Universe/Backports > build rules, Debian/Universe/Backports can use our building rules, what is > the effort duplication you are talking about ? Not if you work separately. If you've created a proper package, why not get it uploaded and backported? > We would not keep "wasting" efforts for 1 year unless we got very positive > feedback from our work, which we do. I did not present this project at the > beginning because I knew I would run the risk of getting comments like this > that would probably break my motivation, comments for which I was not > prepared, I was lacking he skills, know-how, team collaboration and strong > believe on the value of the project, something which I do have now. Automatix has lots of positive feedback too. It doesn't mean it's a good thing for users to be using. Stop and consider for a minute that the reason you get positive feedback is that you are packaging updates and such and NOT putting them in the official repositories. It's a self fullfiling prophecy. > I do respect your personal opinion about the "waste of time" which is the > getdeb work, however I do not appreciate that you use the word "official" > to shield your personal opinion. There are official repositories. I didn't make that up. I do think there is a lot of duplication of effort. > We may become an official project, or we may not, it will depend on our > ability to improve our processes and trustworthy, still, this is not a > present objective, we still have a long road to run on the technical side. > > Our work is about collaboration, not about competition. How so? I note that you are distributing gnucash 2.2.1 for Feisty: http://www.getdeb.net/app.php?name=GnuCash ht
Re: GetDeb Project
On Tuesday 16 October 2007 16:19, João Pinto wrote: > Once we skip that phase of the dialog, we will get into the, "How can we > collaborate?", which I was trying to get into on my previous mail, > regarding the ability to upload packages to a backports automated building > process. By policy (given out by the Ubuntu Tech Board) backports only come from the developmental repository. I don't understand why you keep wanting to bypass that step. The packaging standards for backports are the same as for regular Ubuntu development repositories. What would uploading packages for automated building accomplish? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 16:52, João Pinto wrote: top posting fixed. > 2007/10/16, Scott Kitterman <[EMAIL PROTECTED]>: > > By policy (given out by the Ubuntu Tech Board) backports only come from > > the > > developmental repository. I don't understand why you keep wanting to > > bypass > > that step. The packaging standards for backports are the same as for > > regular > > Ubuntu development repositories. > > > > What would uploading packages for automated building accomplish? > > > > Scott K > Hello, > That policy is development oriented. Our target is the "current" release. > > A backport may be complex or not, it may even be impossible (it may depend > on core library upgrades), making sure a package can be successfully build > and successfully runs on both development and current, requires twice the > time for the reviewing (which is the most important process), we have a > large requests queue already, we can't afford that extra effort. For virtually all backports a package from the development release can be built and used in the current release. So far I've only seen one source backport (where the source package needs to be changed) for Feisty from Gutsy. For a well designed package the extra effort is nil. > Our focus is the current release version, not the development version, for > the development version there is already the MOTU team which does have much > more human resources and which does a great job. Well we could certainly use more help. Getting things into the developemental release and then backporting only need add a few days to the process. Both could be served for essentially the same effort. > Uploading to the automated system would guarantee that you would get all > the packages that we produce, I understood that your main concern is that > we also provide packages to the official repositories, on this case because > we work with current version, it would be for backports. If you could get the Tech Board to buy off on that, then it could be considered, but there would still have to be a packaging review which is the majority of the delay regardless of if you are targeting the current release or the development release. Having done both a fair amount of backporting and packaging for developmental releases, I don't understand your objection. In practice the problems you raise just don't come up very often. I understand you have a nice web front end (and that's fine). My concern is that you are producing duplicate packages when if we were working together we could get more done. You keep saying you want to work together, but that you won't. I don't understand which you want. Are you going to remove gnucash from getdeb now that you know it's available through backports? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 17:27, João Pinto wrote: > Hello, > I am not going to touch the gnucash package because the "Feisty" getdeb > archive is frozen. > When a new release arrives, we also get a frozen archive, on our case, for > the past release. > > Still, you can request it's removal by reporting is as a bug at: > https://launchpad.net/getdeb.net/ > > If we believe there is a good reason for an exception, the package will be > removed. OK. Well then I guess already in an Ubuntu archive isn't a good reason (you don't need me to write a bug report for that as you already know). I still don't see how you want to cooperate? Not distributing packages available through the archive would be a good start. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 19:06, Krzysztof Lichota wrote: > João Pinto napisał(a): > >>I note that you are distributing gnucash 2.2.1 for Feisty: > > > > Possible causes: > > - We have packaged it before it was available on backports > > - We missed to verify that it was on backports, or for some odd reason > > we decided to publish it knowing that it was already available on > > backports, regardless of the reason, it was great for those more than > > 500 users that installed it from getdeb, if we did some duplicated work, > > bad luck for us, getdeb. > > Backports is sometimes not a proper solution, because it causes upgrade > to all the newest versions of a lot of packages. For example, if user > wants to upgrade amarok but not kopete, he can do it using GetDeb, but > he cannot do it using backports (forget package pinning/repository > priorities, it is in no way intuitive and cannot be done by "average > users"). > > Just my 2c. > Generally I enable backports, install what I want, and the disable it again. That I think most people can do. It doesn't "cause upgrade to all the newest versions of a lot of packages". That only happens if the user specifically requests it. Of course it's not rare for people to run with -proposed (even) enabled all the time. We recently had a problem with an svn upload to feisty-proposed and quite a few people tripped on the bug who apparently had no idea they were downloading from a testing repository. Getting repos enabled does not appear to be a major problem. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Tuesday 16 October 2007 17:57, Scott Kitterman wrote: > On Tuesday 16 October 2007 17:27, João Pinto wrote: > > Hello, > > I am not going to touch the gnucash package because the "Feisty" getdeb > > archive is frozen. > > When a new release arrives, we also get a frozen archive, on our case, > > for the past release. > > > > Still, you can request it's removal by reporting is as a bug at: > > https://launchpad.net/getdeb.net/ > > > > If we believe there is a good reason for an exception, the package will > > be removed. > > OK. Well then I guess already in an Ubuntu archive isn't a good reason > (you don't need me to write a bug report for that as you already know). On Tuesday 16 October 2007 19:06, Krzysztof Lichota wrote: > Backports is sometimes not a proper solution, because it causes upgrade > to all the newest versions of a lot of packages. For example, if user > wants to upgrade amarok but not kopete, he can do it using GetDeb, but > he cannot do it using backports (forget package pinning/repository > priorities, it is in no way intuitive and cannot be done by "average > users"). I was thinking about this some more. My objection isn't to the installation method, but to the packages. Someone earlier in the thread mentioned the benifits of the web front end that Getdeb provides. Rather than remove something like gnucash from getdeb, what really needs to happen is just pointint from the getdeb package to the Ubuntu one. In the gnucash case it would be changing: http://www.getdeb.net/download.php?release=1496&fpos=0 http://www.getdeb.net/download.php?release=1496&fpos=1 http://www.getdeb.net/download.php?release=1496&fpos=2 with http://launchpadlibrarian.net/9958499/gnucash_2.2.1-1ubuntu4%7Efeisty1_i386.deb http://launchpadlibrarian.net/9958498/gnucash-common_2.2.1-1ubuntu4%7Efeisty1_all.deb http://launchpadlibrarian.net/9959217/gnucash-docs_2.2.0-1%7Efeisty1_all.deb The web front end could stay. This would have a number of advantages: Reduced storage and bandwidth usage for getdeb Fewer packages users have to uninstall before an upgrade Fewer issues due to unofficial package use How about something like that? I've no objections to that approach myself. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Archive frozen for Gutsy release
On Tuesday 16 October 2007 19:32, Matt Hoy wrote: > Steve, > > Pretty major bug, yet seemingly simple fix, affects a fair number of > people. > > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/127773 > > Booting 2.6.20-16-generic gives me a regular, working battery. > > 2.6.22-14-generic is the problem. > What's the fix? I'd love to try it out? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Archive frozen for Gutsy release
On Tuesday 16 October 2007 21:58, Conrad Knauer wrote: > On 10/16/07, Scott Kitterman <[EMAIL PROTECTED]> wrote: > > > Pretty major bug, yet seemingly simple fix, affects a fair number of > > > people. > > > > > > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/127773 > > > > > > Booting 2.6.20-16-generic gives me a regular, working battery. > > > > > > 2.6.22-14-generic is the problem. > > > > What's the fix? I'd love to try it out? > > Based on the comment and the description in the linked bug, it is the > linux-image-2.6.22-14-generic package; he is saying that a > linux-image-2.6.22-16-generic fixes things. And yet, AFAIK, no such > package exists... > > ??? > > Yes, I'm confused too. > No, it was 2.6.20-16 (e.g. the current Feisty kernel). I agree this is a kernel regression, but I'm not aware of any fix. I have an L400 too, so I'd really like to see this fixed (I'll be sticking with Feisty for anything but development work because of this and a power management bug). Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Wednesday 17 October 2007 06:47, Krzysztof Lichota wrote: > Scott Kitterman napisał(a): > > I was thinking about this some more. My objection isn't to the > > installation method, but to the packages. Someone earlier in the thread > > mentioned the benifits of the web front end that Getdeb provides. > > > > Rather than remove something like gnucash from getdeb, what really needs > > to happen is just pointint from the getdeb package to the Ubuntu one. In > > the gnucash case it would be changing: > > > > http://www.getdeb.net/download.php?release=1496&fpos=0 > > http://www.getdeb.net/download.php?release=1496&fpos=1 > > http://www.getdeb.net/download.php?release=1496&fpos=2 > > > > with > > > > http://launchpadlibrarian.net/9958499/gnucash_2.2.1-1ubuntu4%7Efeisty1_i3 > >86.deb > > http://launchpadlibrarian.net/9958498/gnucash-common_2.2.1-1ubuntu4%7Efei > >sty1_all.deb > > http://launchpadlibrarian.net/9959217/gnucash-docs_2.2.0-1%7Efeisty1_all. > >deb > > > > The web front end could stay. > > > > This would have a number of advantages: > > > > Reduced storage and bandwidth usage for getdeb > > Fewer packages users have to uninstall before an upgrade > > Fewer issues due to unofficial package use > > > > How about something like that? I've no objections to that approach > > myself. > > I think it is a good idea, but I see 2 problems: > 1. Ubuntu should provide links to debs which do not change in time or > some way of automatically feeding changes to deb names to getdeb, so > that updates do not require manual intervention. I'd like to be able to dget source from LP too, but it's reallly not how their system is designed, but I don't think the links actually change over time. > 2. Pure .deb packages are not signed (as far as I understand APT > system). Only repos are. So the security problem stays the same. I disagree. If I'm pulling a .deb from LP over https, I have a lot more confidence in that than one that's signed, but from some external site. Not ideal, but it's better. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GetDeb Project
On Wednesday 17 October 2007 10:15, João Pinto wrote: > > I disagree. If I'm pulling a .deb from LP over https, I have a lot more > > confidence in that than one that's signed, but from some external site. > > Not > > > ideal, but it's better. > > Scott, > if your trust is based on the URL of the download and not on the PGP > signature validation, then you do not care or you do not understand what > is the PGP signature role. > > I strongly recommend you some reading like: > http://cryptnet.net/fdp/crypto/strong_distro.html > http://wiki.debian.org/SecureApt > The fact that you signed a package and the signature validates just means that I got what you packaged and signed. My trust in that package is no higher than my trust in you. If I download a file from LP, I know I got the file than Ubuntu developers uploaded (unless LP has been hacked, a risk I'll consider nil). Ideally the .debs off LP would be signed, but I'll take that over packages from a site that has repeatedly stated they won't meet Ubuntu packaging standards with no hesitation. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
