[Bug 1783895]
Installing latest upower solved my issues. It appears that upower-pm-utils form of 0.9 does not have the new lid events api. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783895 Title: Screen locking fails on Suspend/Resume for laptop lid-switch To manage notifications about this bug go to: https://bugs.launchpad.net/xfce4-session/+bug/1783895/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 145604]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/145604 Title: VRGB sub-pixel hinting causes black-on-black text rendering Status in libcairo - cairo vector graphics library: Confirmed Status in cairo package in Ubuntu: Triaged Status in compiz package in Ubuntu: Invalid Status in compiz-fusion-plugins-main package in Ubuntu: Invalid Bug description: Binary package hint: libcairo2 There is a long-standing problem (Gutsy, Hardy, Intrepid - possibly Jaunty too) with sub-pixel rendering which affects metacity or compiz composition (see the images attached to this bug) when VRGB is chosen as the sub-pixel format. Comment #15 by MoMaT demonstrates a non- compiz scenario. My comments #2 and #10 demonstrate the issue with Compiz enabled. The underlying issue essentially seems to be: where should sub-pixel rendering should be done - in libcairo or in the font renderer (FreeType in this case) ? There have been two versions of the Ubuntu patch in libcairo/libcairo2. Reports seem to suggest that both versions may be responsible for the VRGB problem (however, that supposition needs checking - see Bob McElrath's comment #19). We need to be aware that libcairo (libcairo 1.5.4 in Universe) and libcairo2 (cairo 1.6.0 in Main) are similarly patched and will need similar fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/libcairo/+bug/145604/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 145604]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/145604 Title: VRGB sub-pixel hinting causes black-on-black text rendering Status in libcairo - cairo vector graphics library: Confirmed Status in cairo package in Ubuntu: Triaged Status in compiz package in Ubuntu: Invalid Status in compiz-fusion-plugins-main package in Ubuntu: Invalid Bug description: Binary package hint: libcairo2 There is a long-standing problem (Gutsy, Hardy, Intrepid - possibly Jaunty too) with sub-pixel rendering which affects metacity or compiz composition (see the images attached to this bug) when VRGB is chosen as the sub-pixel format. Comment #15 by MoMaT demonstrates a non- compiz scenario. My comments #2 and #10 demonstrate the issue with Compiz enabled. The underlying issue essentially seems to be: where should sub-pixel rendering should be done - in libcairo or in the font renderer (FreeType in this case) ? There have been two versions of the Ubuntu patch in libcairo/libcairo2. Reports seem to suggest that both versions may be responsible for the VRGB problem (however, that supposition needs checking - see Bob McElrath's comment #19). We need to be aware that libcairo (libcairo 1.5.4 in Universe) and libcairo2 (cairo 1.6.0 in Main) are similarly patched and will need similar fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/libcairo/+bug/145604/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 145604]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/145604 Title: VRGB sub-pixel hinting causes black-on-black text rendering To manage notifications about this bug go to: https://bugs.launchpad.net/libcairo/+bug/145604/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Compiz] [Bug 145604]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of compiz packagers, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/145604 Title: VRGB sub-pixel hinting causes black-on-black text rendering To manage notifications about this bug go to: https://bugs.launchpad.net/libcairo/+bug/145604/+subscriptions ___ Mailing list: https://launchpad.net/~compiz Post to : compiz@lists.launchpad.net Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
[Bug 164640]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/164640 Title: Build Firefox 3 against a subpixel-patched cairo To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/164640/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 164640]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to fontconfig in Ubuntu. https://bugs.launchpad.net/bugs/164640 Title: Build Firefox 3 against a subpixel-patched cairo Status in Fontconfig - Font Configuration Library: Fix Released Status in libcairo - cairo vector graphics library: Confirmed Status in fontconfig package in Ubuntu: Fix Released Status in libcairo package in Ubuntu: Fix Released Status in xulrunner-1.9 package in Ubuntu: Fix Released Bug description: Binary package hint: firefox-3.0 In Ubuntu 7.10 and newer, Firefox 3.0 looks out of place with subpixel rendering enabled, due to the fact that it uses an unpatched, bundled version of Cairo. The patch should be ported to Cairo 1.5 and applied in the firefox-3.0 package. To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/164640/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 164640]
Created attachment 40431 Allow changing of hintstyles by FC http://weirdfellow.wordpress.com/2010/08/01/patching-cairo/ -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to fontconfig in Ubuntu. https://bugs.launchpad.net/bugs/164640 Title: Build Firefox 3 against a subpixel-patched cairo Status in Fontconfig - Font Configuration Library: Fix Released Status in libcairo - cairo vector graphics library: Confirmed Status in fontconfig package in Ubuntu: Fix Released Status in libcairo package in Ubuntu: Fix Released Status in xulrunner-1.9 package in Ubuntu: Fix Released Bug description: Binary package hint: firefox-3.0 In Ubuntu 7.10 and newer, Firefox 3.0 looks out of place with subpixel rendering enabled, due to the fact that it uses an unpatched, bundled version of Cairo. The patch should be ported to Cairo 1.5 and applied in the firefox-3.0 package. To manage notifications about this bug go to: https://bugs.launchpad.net/fontconfig/+bug/164640/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Bug 818730] Re: Ubuntu 11.10 Alpha 2 Oneiric LiveCD Crash on Acer AO522
** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/818730 Title: Ubuntu 11.10 Alpha 2 Oneiric LiveCD Crash on Acer AO522 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818730/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Arm-netbook] Single-Core Cortex A9 1ghz, ECC DDR3 RAM available soon
Hello everyone, I'm glad to hear that we advanced in negotiations even that little. In my opinion, just getting started is already good invariably of how we do it. Starting with entry level mainstream SoC is completely OK. We can scale up it later as many times as we want. About the price. Almost all of SoCs nowadays score the same on openness and features. The main price factor today is core architecture * MHz * nCores, rather than feature set. So this is scaleble as well. On 13 August 2011 10:39, Luke Kenneth Casson Leighton l...@lkcl.net wrote: On Sat, Aug 13, 2011 at 5:58 PM, Gordan Bobic gor...@bobich.net wrote: On 08/13/2011 02:46 PM, Luke Kenneth Casson Leighton wrote: ok, right. continuing on the discussion of upcoming and/or available Cortex A9 systems, i heard back from one of the CPU manufacturers (can't say which one), and they are sampling a new CPU next month. rough spec: * Single-Core Cortex A9, 1ghz * MALI 400MP 3D * SATA-II would anybody else be interested to see a small panda-like board (4in x 3in or so) or other type of board be brought into existence based around this CPU? Depends on the cost. Freescale are pretty competitive in this arena with iMX53. yeah. if so, what would you be prepared to do to make that happen and, also, what retail price would you be prepared to pay for it? Based on the competition maybe $170 for a 2GB one if it has ECC RAM. ok - good to know. bear in mind that the CPU's manufacturer has: * a general understanding of and respect for free software licenses including the GPL. What about GPU drivers supporting all the recent Xorg ABIs? I'm not an OSS faschist who demans everyting be OSS - I am prepred to overlook the OSS-ness of drivers and detailed documentedness of the GPU if the drivers are of decent quality, feature-complete and continuously supported. it's MALI 400MP-based. the git repository with the linux kernel already has the mali shim linux kernel driver added: that means that the libGLES.so.2 proprietary system library should work, and the xorg x11 driver just happily sit on top of that. i don't forsee any problems, but at some point in the next few days/weeks i'm likely to have to test this out (using a demo unit which has the precursor processor in it). it's currently all running android so i'll have to hack together a debian armhf for it. deep joy. they also have a system library for the on-board Video CODEC DSP, which those who understand the subtleties of the GPL will appreciate qualifies for an exemption under the GPL, even though it's proprietary. they've released an example application which utilises libffmpeg (enhancements to use their system library have already been made) and is a working video player. for the freedombox to fulfil its sponsor commitments (bearing in mind, as we know, the freedombox project is not a hardware project despite the word box being in the name of the project but they still have to deliver a number of actual physical boxes to the pledgeware sponsors), i'd say that this CPU and the fact that its manufacturer respects the GPL fits the requirements far better than the chosen marvell-based plug computer. That would depend on the quality of the current drivers/libraries that aren't OSS and the ongoing support for them. yeah - proprietary's a bitch, whichever way you look at it. you wouldn't believe the fun and games i'm hearing about how these SoC vendors are having a blast with adobe flash... they have to wait in line for adobe to bother to compile up flash... with *their* proprietary hardware video extension libraries! what a hoot. anyway, leaving that aside: there are two areas of stupidity^H^H^H^H^H^Hproprietary. a) hardware-accelerated CODEC library b) MALI-400MP. the first: well... you just have to trust them. and, once you've seen a lowly single-core processor smoke a dual-core intel processor at 1080p30 video playback, you've seen it all. it works, or it doesn't. and, if it works, it will _stay_ working. the second: you have to trust and put your faith in ARM (with their stupid deal with MediaTek). Hallelujah, brothers: _every_ CPU manufacturer using MALI is in the same boat. so that means Samsung Enyxos, Telechips, AMLogic - everybody. bottom line: it's not a nice situation, but tough titty, we have to keep the pressure up. perhaps the freedombox project might like, if nothing else, to use this CPU as leverage to accelerate marvell out of their self-imposed stupor by threatening to pull the plug (ha ha) if they don't get with the C21st? please bear in mind that there is a window of opportunity lasting a couple of weeks in which i can potentially persuade the CPU designer to come up with a demo / engineering board that would actually be a useful saleable product in its own right... ... and that i can *only* do that if there is a demonstrable need for such. The problem is that
Re: [Freedombox-discuss] [Arm-netbook] Single-Core Cortex A9 1ghz, ECC DDR3 RAM available soon
Hello everyone, I'm glad to hear that we advanced in negotiations even that little. In my opinion, just getting started is already good invariably of how we do it. Starting with entry level mainstream SoC is completely OK. We can scale up it later as many times as we want. About the price. Almost all of SoCs nowadays score the same on openness and features. The main price factor today is core architecture * MHz * nCores, rather than feature set. So this is scaleble as well. On 13 August 2011 10:39, Luke Kenneth Casson Leighton l...@lkcl.net wrote: On Sat, Aug 13, 2011 at 5:58 PM, Gordan Bobic gor...@bobich.net wrote: On 08/13/2011 02:46 PM, Luke Kenneth Casson Leighton wrote: ok, right. continuing on the discussion of upcoming and/or available Cortex A9 systems, i heard back from one of the CPU manufacturers (can't say which one), and they are sampling a new CPU next month. rough spec: * Single-Core Cortex A9, 1ghz * MALI 400MP 3D * SATA-II would anybody else be interested to see a small panda-like board (4in x 3in or so) or other type of board be brought into existence based around this CPU? Depends on the cost. Freescale are pretty competitive in this arena with iMX53. yeah. if so, what would you be prepared to do to make that happen and, also, what retail price would you be prepared to pay for it? Based on the competition maybe $170 for a 2GB one if it has ECC RAM. ok - good to know. bear in mind that the CPU's manufacturer has: * a general understanding of and respect for free software licenses including the GPL. What about GPU drivers supporting all the recent Xorg ABIs? I'm not an OSS faschist who demans everyting be OSS - I am prepred to overlook the OSS-ness of drivers and detailed documentedness of the GPU if the drivers are of decent quality, feature-complete and continuously supported. it's MALI 400MP-based. the git repository with the linux kernel already has the mali shim linux kernel driver added: that means that the libGLES.so.2 proprietary system library should work, and the xorg x11 driver just happily sit on top of that. i don't forsee any problems, but at some point in the next few days/weeks i'm likely to have to test this out (using a demo unit which has the precursor processor in it). it's currently all running android so i'll have to hack together a debian armhf for it. deep joy. they also have a system library for the on-board Video CODEC DSP, which those who understand the subtleties of the GPL will appreciate qualifies for an exemption under the GPL, even though it's proprietary. they've released an example application which utilises libffmpeg (enhancements to use their system library have already been made) and is a working video player. for the freedombox to fulfil its sponsor commitments (bearing in mind, as we know, the freedombox project is not a hardware project despite the word box being in the name of the project but they still have to deliver a number of actual physical boxes to the pledgeware sponsors), i'd say that this CPU and the fact that its manufacturer respects the GPL fits the requirements far better than the chosen marvell-based plug computer. That would depend on the quality of the current drivers/libraries that aren't OSS and the ongoing support for them. yeah - proprietary's a bitch, whichever way you look at it. you wouldn't believe the fun and games i'm hearing about how these SoC vendors are having a blast with adobe flash... they have to wait in line for adobe to bother to compile up flash... with *their* proprietary hardware video extension libraries! what a hoot. anyway, leaving that aside: there are two areas of stupidity^H^H^H^H^H^Hproprietary. a) hardware-accelerated CODEC library b) MALI-400MP. the first: well... you just have to trust them. and, once you've seen a lowly single-core processor smoke a dual-core intel processor at 1080p30 video playback, you've seen it all. it works, or it doesn't. and, if it works, it will _stay_ working. the second: you have to trust and put your faith in ARM (with their stupid deal with MediaTek). Hallelujah, brothers: _every_ CPU manufacturer using MALI is in the same boat. so that means Samsung Enyxos, Telechips, AMLogic - everybody. bottom line: it's not a nice situation, but tough titty, we have to keep the pressure up. perhaps the freedombox project might like, if nothing else, to use this CPU as leverage to accelerate marvell out of their self-imposed stupor by threatening to pull the plug (ha ha) if they don't get with the C21st? please bear in mind that there is a window of opportunity lasting a couple of weeks in which i can potentially persuade the CPU designer to come up with a demo / engineering board that would actually be a useful saleable product in its own right... ... and that i can *only* do that if there is a demonstrable need for such. The problem is that
[asterisk-users] REGISTER forwarding problem
Hello, I have a following setup: UA opensips REGISTER asterisk userdb, where opensips forwards register requests. For some reasons Asterisk 1.6.2.18 doesn't want to accept REGISTER forwarded through opensips. Here is SIP trace http://pastebin.com/ebV62r7b . What can possibly cause this behaviour? -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] REGISTER forwarding problem
I see 401, but asterisk has my proxy in its trunk list. Can this be caused by anything else? Is there any way to do it without using path extension? On 4 August 2011 10:19, Alex Balashov abalas...@evaristesys.com wrote: It doesn't consider the OpenSIPS host an authorised peer, so it's simply issuing the usual 401 challenge. Also, Asterisk doesn't currently support the Path extension, and you can't use Record-Route in REGISTERs. If you want your proxy to stay in the loop of subsequent traffic, you will need to come up with some way to get Asterisk to reach the UA through it. On 08/04/2011 12:59 PM, Baybal Ni wrote: Hello, I have a following setup: UA opensips REGISTER asterisk userdb, where opensips forwards register requests. For some reasons Asterisk 1.6.2.18 doesn't want to accept REGISTER forwarded through opensips. Here is SIP trace http://pastebin.com/ebV62r7b . What can possibly cause this behaviour? -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Bug 767975] Re: Video does not return after sleep with AMD E-350 Fusion APU and ATI closed driver (Natty Narwal Beta)
Stefan, can you upload your xorg.conf? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/767975 Title: Video does not return after sleep with AMD E-350 Fusion APU and ATI closed driver (Natty Narwal Beta) -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 745245] Re: Seahorse cannot set up SSH keys for login servers
Can reproduce -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to seahorse in Ubuntu. https://bugs.launchpad.net/bugs/745245 Title: Seahorse cannot set up SSH keys for login servers -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 745245] Re: Seahorse cannot set up SSH keys for login servers
Can reproduce -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/745245 Title: Seahorse cannot set up SSH keys for login servers -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 741114] Re: pc freeze 2.6.38 on ubuntu 10.10 and 11.04 probably caused by wifi driver
*** This bug is a duplicate of bug 735431 *** https://bugs.launchpad.net/bugs/735431 Can confirm. Acer 522. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/741114 Title: pc freeze 2.6.38 on ubuntu 10.10 and 11.04 probably caused by wifi driver -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Using .tar.xz only on ftp.gnome.org
On 21 March 2011 15:10, Josselin Mouette j...@debian.org wrote: Le lundi 21 mars 2011 à 15:50 +0100, Olav Vitters a écrit : I would be interested to see download stats for the xd3 files once they go live! xdelta3 is very cool, even if few people use it. Due to the feedback from the last discussion, I didn't develop it. I can do so, should be relatively easy in the new 'install-module' (actually called ftpadmin; install-module would be an alias) xdelta3 support would be nice, but frankly it would only be used in corner cases. If I consider our example to be representative, this would require significant hackery in our download scripts, with a very small benefit since the generated tarball has to be uploaded to our FTP server after the build, and most developers have ADSL lines, so upload time is a more pregnant problem than download time. (And .xz support *will* reduce upload time.) OTOH I’d really appreciate to see digital signatures along with the tarballs. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `- […] I will see what I can do for you.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list What about making a whole release tarball and making deltas for it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On 6 February 2011 12:52, Dave Neary dne...@gnome.org wrote: Hi, Gendre Sebastien wrote: Le samedi 05 février 2011 à 11:43 -0600, Paul Cutler a écrit : Development is not a democracy For a personal project, no. But Gnome is not your personal project, it's a community project. The light of this, you have a duty of openness to the whole community. A community project means exactly what Paul says - it is not a democracy. Your argument is one of the main fallacies circulated about free software - just because the project is free software does not mean that everyone's opinion carries equal weight. You have an array of forums for expressing your opinion, as do I, but in the end of the day, the most important opinion is the one which is expressed in code. So far I have mostly attended one-way debat with designers. Some people arrive with good arguments but they are ignored or they receive ridiculous and/or void cons-arguments. Impossible to have a good debat. I think it is important for designers to have a good productive relationship with some key developers. I think it's important for the designers to be competent, and to have the trust of the developers. And honestly, the opinion of people outside that group carry much less weight. Sure, designers developers need to avoid presenting plans products carved in marble, but what you call good arguments might not be good arguments to members of the core team of Shell. In the end of the day, changing something which is a core concept of a project probably needs a *lot* of evidence that the change would be a positive one. And for things which are accessory, there would at least need to be a decent level of agreement on a proposed alternative. Changing design should be just as hard and have just as high a bar as proposing a patch for a feature. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Guys, for a sake of a sanity. I've been around gnome since pre 2.0 times. And all times up to now we supposed that OSS is about democratic process, where programmers are not told buy big enterprise daddy what to write. Now, you former windows/sco/ibm/sun programmers are coming and saying that is wasn't. Yes, there are some big developers who can steer the way of a project, but nobody up to now just came I said what you have just said! You can't complete your shell if you drop off all the remaining developers of the boat. Shell is already a buggy hell, that will take many months just to stabilize. Now, probably you realize that simply dumping your privately developed project on a community in hope that it will accept and maintain it doesn't work. If you want to have your shell working, just change your position on this matter. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fanza Icon Set
It looks too much apple like, anyways you better to ask gnome-art team. On 23 January 2011 03:16, Nick exos...@gmail.com wrote: I haven't seen any mention of a new icon set for Gnome 3 (forgive me if I'm mistaken) but could I bring attention to the Faenza Icon set[1]? Is there an opportunity here to engage people outside of the Gnome/Tango sphere and get some nice, seemingly well liked, icons included with the new theme and the new gnome shell? Again, sorry if this has already been discussed but, I figured a bit of discussion on the current state of the icon theme would be a nice thing to bring about anyway. Regards [1] http://tiheum.deviantart.com/art/Faenza-Icons-173323228 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
I cannot believe I am reading this on GNOME central mail list! [ snip ] I cannot believe this topic keeps coming up again and again :-( Linux is not about choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html Guys, I can't believe I'm readeing this again. If linux/OSS wasn't about choice, you wouldn't be here at a first place. I, as a user who never used necrosoft/novelll from my very long 20 years of computer experience just like to tell you. That the freedom of movement between all of opensource OS'es was the crucial factor that it was: Chosen for use in enterprise environment, where you your data worth money and you would like to preserve it between OS migration Chosen for use in global scale research projects, simply because no commercial solution would ever provide that level of standartisation that OSS have Chosen as a base level for most of advanced embedded electronics, for a simple fact that it has standards and no competing product is anything more that code blobs without documentation Now, tell me what you and Mr. Olav are trying to infer with this discussion? And lets come back to constructive discussion. If you suggest to deprecate old gnome 2 experience, you should provide something compatible, similiar or better. And what you have: Shell is not better, it's a clearly a degradation of user experience. It was targeted on downsized desktops, but doesn't fit here and we are simply left running desktop sized panel with scaled proportionately giantic icons. Shell simply doesn't have similiar user experience. At current stage it's nothing more than set of launcher icons on fixed panel that can't be even moved around. Imagine what a pain whould it be to work wiht it on 21:9 screen or xinerama? Besides this it simply doesn't work in xinerama configuration yet (Mutter hangs). Shell is simply not working as advertised yet (black windows bug, slow) Shell development is driven by a closed club of developers that has incepted the idea without taking anybodys opinion into consideration. It's clearly lacks ergonomics, design is poor, doesn't comfort user at all. Please fix it, and then come with your idea after it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Confused as well. On 14 December 2010 16:49, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I am confused, what's the story with gnome-panel and gnome-applets in 3.0? Are they in, are they out? If gnome 3 is to support gnome2 compat mode, both of these components should stay in for some while, right? Currently, the situation in in jhbuild is very strange: gnome-panel is still there, gnome-applets are gone. Is this planned? Who'd need the panel without the applets? Cheers, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
is it possible to make udisks working without policykit?
___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: The desktop in Gnome 3
I think neither solution is optimal. I'm pro on idea of letting shell and nautilus to coexist just like browser and spatial mode of nautilus. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [PATCH] b43/b43legacy - Credit Broadcom with enabling the development of the drivers
Actually, it's totally legal to write any software for wireless hardware. The only legal limitations are on manufacturer's side rather than on consumer's side. And existence of hackable drivers doesn't affect manufacturers approval by FTC in any way. If FTC workers are retarded to a degree that they rate emission rates basing on software, it's nobody's fault beside themselves. It's totally legal to hack radio equipment to operate outside of license's diapason, the only criminal liability comes if you try to impair operations of emergency services and military communication systems. Not to mention the fact that the most of world's 480 countries are living outside of ITUdom of the developed world, which means that they doesn't have even most common radio regulations. On 20 September 2010 21:01, Peter Stuge pe...@stuge.se wrote: Ehud Gavron wrote: It is not up to us to ...deal with regulatory considerations... No, you see, that's wrong because no one else was, That .. makes no sense if I try to figure out what you intended. I agree with you both. Developers are good at development and in an ideal world that's what we should focus on. Unfortunately our world is not always ideal, so a project such as Linux can get honest (if young) interest from vendors when developers not only do development but do it with vendors' problems in mind. It's certainly not up to us - but I think we benefit from stepping up and solving the problem. Being a technical guy you could say that I'm not a fan of artificial limitations, and clearly writing code to *support* such limitations will add some overhead. But on the other hand I have to play the cards I've been dealt if I want to stay in the game, as do vendors, and I think it is nice that Linux solves the (legal) problem for now. I certainly agree that it is a kludge fix and in the wrong place. Unfortunately fixing the law where it is broken takes a long time. :\ The root of problem is the law, but by enabling those who need (or want) to comply with (old, broken) regulation we can get them more involved in Linux and that gets us technical, political and business advantages over other projects that may have been considered alternatives. In the short term it can be bumpy to get a new vendor involved but in the long term I, like Luis, think that it is a win. By applying our development skills to *how* they can comply we can also make sure that we only make compromises where required, and maybe we can even offer something for brand new technology developments. Finally, to play nice with the relevant authorities I think the choice to enable self-policing (if you will) by default makes sense. Of course it must be easy to change for those who want to or need to, and I believe that it is. It's time for you to go to bed. It sure looked like Luis was in a hurry when he wrote the email. It wasn't the best english I've seen and neither is mine. I guess that he felt that it was important to reply, to try to clarify his point and his reasoning, so that you would have a better chance of seeing the issue also from his point of view. //Peter ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: Can developers add a switch for bluetooth coexistence?
I successfully replace my piece of paper with echo on /sys/class/bluetooth/hci0/power/control It looks that the problem was broken power management. On 10 August 2010 13:57, Baybal Ni nikuli...@gmail.com wrote: On 10 August 2010 13:29, Larry Finger larry.fin...@lwfinger.net wrote: On 08/10/2010 02:55 PM, Baybal Ni wrote: On 10 August 2010 05:45, Larry Finger larry.fin...@lwfinger.net wrote: On 08/10/2010 04:36 AM, Baybal Ni wrote: The problem is that I need to turn the coexistence off. I'm using a piece of paper to prevent coexistence pins from contacting. I think that loading b43 with 'modprobe b43 btcoex=0' should do what you want. Have you tried that? Larry It doesn't work for me. Did you unload it first? AFAICT, that option should do the same as you are doing with your piece of paper. If not, you will have to debug it. I don't have the hardware. Larry Yes, I unloaded it and rebooted a few times, trying other switches like hwpctl and their combinations. What kind of debugging output do you want me to get? But I'm somehow confident that this may not be a bad hardware problem as ifconfig wlan1 down allows my bluetooth devices to operate normally. And as I can understand ifconfig down doesn't perform a normal hardware power off. ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Can developers add a switch for bluetooth coexistence?
The problem is that when it's on my bluetooth mouse laggs, but when I'm insulating the coexistance system pins it works just perfect. ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: Can developers add a switch for bluetooth coexistence?
The problem is that I need to turn the coexistence off. I'm using a piece of paper to prevent coexistence pins from contacting. On 10 August 2010 02:33, Éric Piel e.a.b.p...@tudelft.nl wrote: Op 10-08-10 10:42, Baybal Ni schreef: The problem is that when it's on my bluetooth mouse laggs, but when I'm insulating the coexistance system pins it works just perfect. Strange, on http://linuxwireless.org/en/users/Drivers/b43 it says that Bluetooth coexistence protection works. What do you mean by insulating the coexistance system pins? Are physically changing the connections on your board? Eric ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Why I can't compile upower without policykit and other *kit stuff?
Why I can't compile upower without policykit and other *kit stuff? ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework. On 7 May 2010 01:26, Richard Hughes hughsi...@gmail.com wrote: On 7 May 2010 09:02, Baybal Ni nikuli...@gmail.com wrote: Why I can't compile upower without pol... Because UPower uses PolicyKit as a security framework. Why do you want to change it? Richard. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Fwd: Why I can't compile upower without policykit and other *kit stuff?
On 7 May 2010 05:36, David Zeuthen zeut...@gmail.com wrote: On Fri, May 7, 2010 at 4:34 AM, Baybal Ni nikuli...@gmail.com wrote: Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework. Can you elaborate on the last statement please? David Just for its extensive use of such a suboptimal thing as suid it can be banished from some distros which accents on security. Secondly, a hack to pk client means that pk will issue whatever permissions set by user of defaults without further checks. And, thirdly a simplest hack will be launching a fake dbus, and exploiting it for whatever reason. PK utilises pam, and thus should be able to do things is a somehow more safe way, while it's not utilising even a glimpse of its features. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: Why I can't compile upower without policykit and other *kit stuff?
On 7 May 2010 01:34, Baybal Ni nikuli...@gmail.com wrote: Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework. On 7 May 2010 01:26, Richard Hughes hughsi...@gmail.com wrote: On 7 May 2010 09:02, Baybal Ni nikuli...@gmail.com wrote: Why I can't compile upower without pol... Because UPower uses PolicyKit as a security framework. Why do you want to change it? Richard. Just for its extensive use of such a suboptimal thing as suid it can be banished from some distros which accents on security. Secondly, a hack to pk client means that pk will issue whatever permissions set by user of defaults without further checks. And, thirdly a simplest hack will be launching a fake dbus, and exploiting it for whatever reason. PK utilises pam, and thus should be able to do things is a somehow more safe way, while it's not utilising even a glimpse of its features. ___ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Re: [gnome-love] outdated dependencies
On 27 February 2010 16:36, Joost van der Hoff 2noob2ban...@gmail.com wrote: Hi all, I have built gnome 2.30 using JHbuild, however I have given up on some modules which failed to build. I don't remember exactly which ones, but I know the first is ekiga. It fails during the configure phase, requiring ptlib 2.7.0 or higher while 2.6.5 is found. At first this doesn't seem strange, but considering the fact I don't have ptlib installed, so 2.6.5 is the one built by JHbuild, it is. What's more, I went to download.gnome.org/sources looking for ptlib 2.7 but 2.6 is the highest available. Can anyone please update the repos or redirect me to somewhere containing newer versions of dependencies? Thanks in advance, Joost. P.s. ptlib isn't the only outdated dependency, an outdated version of WebKit keeps me from building epiphany, and I might have forgotten about even more outdated dependencies. ___ gnome-love mailing list gnome-love@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-love Yeah, definitely a problem here. I think we can't release 2.30 without dep cleaning ___ gnome-love mailing list gnome-love@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-love
