Re: Screen orientation and backlight sensing for the Nexus 7
On Mon, 21 Jan 2013 17:00:00 +0100, Oliver Grawert wrote: > hi, > > i just uploaded http://paste.ubuntu.com/1555763/ which should do for > now, it would be great if someone could re-implement /usr/bin/acceld in > actual C .. polling like that from a shell script adds some CPU overhead > that we could avoid ... I am looking into what it takes to add this functionality to gnome- settings-daemon that already has support for screen orientation and a certain type of accelerometer. If that does not work out without being too intrusive we should look into making this into C as you suggest. Jani -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Minutes from Developer Membership Board Meeting 2013-01-07
Le 21/01/2013 17:51, Micah Gersten a écrit : Upload rights at the moment conflate membership and upload rights. Therefore, the board has to evaluate the qualifications for both. We do not, in general, feel that it is fair to publicly enumerate the issues Right, Bjoern is applying for upload right so it seems logical he gets reviewed in context of upload rights... we have with individual applications, preferring to express our public concerns in general terms and be more specific in private. We will be sending Bjoern an E-Mail explaining our concerns and ways that he can address them. If he wants, he can choose to share it with anyone after that. When is that planned? He still didn't get those, we still have no clue what to change, and meanwhile he has a SRU and a raring update blocked waiting... It is not an easy job sitting on a governance board. You're responsible for evaluating the work of friends and, sometimes, co-workers. While trying not to hurt feelings or block people's ability to do things, one also has a responsibility to put personal feelings aside and to consider the applications received in the context of the wider project. We always try to be constructive when giving rejections, but it is a difficult area that we will always be able to improve on. We never take any decision lightly — especially not rejections — as we are aware of the negativity they can generate. Most of us are readily available to discuss and guide applicants. Please find us [1] on IRC if you have any questions. I appreciate that the job is not easy, your reply doesn't address the concerns I raised in my initial email though. We still have a community member who has been working full time on maintaining a difficult package for 1.5+ years, got endorsement from 3 members, and he got rejected mostly for "lack of devel releases" and an wrong assumption (no review) ... isn't the project just making the bar too high to join there? Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Minutes from Developer Membership Board Meeting 2013-01-07
On 01/09/2013 01:15 PM, Sebastien Bacher wrote: > Le 09/01/2013 09:13, Cody A.W. Somerville a écrit : >> >> == PerPackageUploader Applications == >> === Bjoern Michaelsen for libreoffice === >> LINK: https://wiki.ubuntu.com/BjoernMichaelsen/DeveloperApplication >> >> VOTE: For: 2 Against: 1 Undecided: 2 >> >> Application was unsuccessful. >> > Hey DMB people, > > I've been reading the meeting log and I'm slightly worried that the > DMB is currently making too hard for contributors to be part of the > project. > > Bjoern has been doing good and hard work on an important package > (libreoffice) for over 1.5 years, he got strong endorsement from 3 > coredevs and he has been getting in touch with some of the DMB member > before applying again (his application got rejected already 6 months > or so ago) and yet that's not enough for him to get ppu on the package > he's working. > > The DMB members who didn't want to +1 his applications mentioned those > reasons: > > - "-1, lack of devel release uploads, still problems with with some > uploads" > - "+0 lack of devel release uploads" > - "+0 [I don't like the idea that we should grant PPU just because > nobody wants to actually take the time to review this package..." > > I've asked on IRC and apparently "lack of devel release uploads" is > because e.g quantal didn't get SRUs from the current versions. > Since when is that a reason to not welcome somebody on board? > Especially when the reason for that is "maintaining the current stable > is enough for one people full time" ... how is that situation even > resolvable, libreoffice is not going to be magically less work to > maintain over time? > > The "nobody wants to actually take the time to review this package" > seems misinformed, the wiki has 3 coredevs vouching for Bjoern who > have sponsored work for him. I will not speak for pitti and didrocks > but I've been reviewing the packages I sponsored, I probably didn't do > a perfect job of it is a complex piece of packaging and I'm not > familiar with its details. > > Could the DMB provides feedback on how to unblock that application? > > Since it's re-election time for part of the DMB soon, it would also be > nice to know what the people, who are going to (re)apply for it, think > of this situation and if they intend to bring some changes to how the > board is running if they get elected > Upload rights at the moment conflate membership and upload rights. Therefore, the board has to evaluate the qualifications for both. We do not, in general, feel that it is fair to publicly enumerate the issues we have with individual applications, preferring to express our public concerns in general terms and be more specific in private. We will be sending Bjoern an E-Mail explaining our concerns and ways that he can address them. If he wants, he can choose to share it with anyone after that. It is not an easy job sitting on a governance board. You're responsible for evaluating the work of friends and, sometimes, co-workers. While trying not to hurt feelings or block people's ability to do things, one also has a responsibility to put personal feelings aside and to consider the applications received in the context of the wider project. We always try to be constructive when giving rejections, but it is a difficult area that we will always be able to improve on. We never take any decision lightly — especially not rejections — as we are aware of the negativity they can generate. Most of us are readily available to discuss and guide applicants. Please find us [1] on IRC if you have any questions. Thanks, Micah Gersten On behalf of the DMB [1] https://launchpad.net/~developer-membership-board/+members -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/raring-proposed] fglrx-installer-updates 2:9.010-0ubuntu4 (Accepted)
On 21/01/13 17:05, Micah Gersten wrote: > On 01/21/2013 09:55 AM, Alberto Milone wrote: >> fglrx-installer-updates (2:9.010-0ubuntu4) raring; urgency=low >> >> * debian/rules: >> - Revert change to separate regen-from-templates from >> the build target. This fixes a FTBFS. >> >> Date: Mon, 21 Jan 2013 16:49:43 +0100 >> Changed-By: Alberto Milone >> Maintainer: Ubuntu Core Developers >> https://launchpad.net/ubuntu/raring/+source/fglrx-installer-updates/2:9.010-0ubuntu4 >> > Looking at the diff [1], the problem seems to have been a lack of a > build-arch target, not the split out. > > Thanks, > Micah > > > [1] > http://launchpadlibrarian.net/129029705/fglrx-installer-updates_2%3A9.010-0ubuntu3_2%3A9.010-0ubuntu4.diff.gz > The build log complained about the lack of the dkms file and I preferred to revert the change before looking again into the problem so as to get the packages at least to build again (they previously built only in pbuilder, not in PPAs or in the archive). This said, I thank you for your suggestion and I promise to try that soon. Cheers, -- Alberto Milone Software Engineer Hardware Enablement Team Professional and Engineering Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/raring-proposed] fglrx-installer-updates 2:9.010-0ubuntu4 (Accepted)
On 01/21/2013 09:55 AM, Alberto Milone wrote: > fglrx-installer-updates (2:9.010-0ubuntu4) raring; urgency=low > > * debian/rules: > - Revert change to separate regen-from-templates from > the build target. This fixes a FTBFS. > > Date: Mon, 21 Jan 2013 16:49:43 +0100 > Changed-By: Alberto Milone > Maintainer: Ubuntu Core Developers > https://launchpad.net/ubuntu/raring/+source/fglrx-installer-updates/2:9.010-0ubuntu4 > Looking at the diff [1], the problem seems to have been a lack of a build-arch target, not the split out. Thanks, Micah [1] http://launchpadlibrarian.net/129029705/fglrx-installer-updates_2%3A9.010-0ubuntu3_2%3A9.010-0ubuntu4.diff.gz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Screen orientation and backlight sensing for the Nexus 7
hi, i just uploaded http://paste.ubuntu.com/1555763/ which should do for now, it would be great if someone could re-implement /usr/bin/acceld in actual C .. polling like that from a shell script adds some CPU overhead that we could avoid ... feel free to fix up any glitches you see with the scripts ciao oli signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Sanitizing the linux crashdump procedures/handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Le 10/01/2013 20:54, Stefan Bader a écrit : > At UDS we had a session about this [1] and I finally found some > time to write up that mail I really wanted to come up with a bit > sooner... > > So right now the kernel-team produces the linux-crashdump > meta-package will will pull in kexec-tools and makedumpfile. The > kexec-tools package contains some init scripts which will create an > apport crash report from the memory dump taken by the kexec-crash > run and submits it. > > For various reasons (see blueprint) we would like to move to use > kdump-tools and remove everything related to create dump files from > kexec-tools. So that package only provides means to use kexec. > Beside other changes this will initially cause the apport crash > reports no longer to be produced. But then the general question > was: do we really want them to be what they are today? If I have > not understood this wrong, we send several megabytes of memory dump > out, then on our side pull in even more megabytes of kernel debug > packages to look at the panic trace which comes from the dmesg > buffer which is only a tiny part of the core file. > > So one outcome I would like to get from this discussion is to > understand better what parts and how exactly those memory dump > reports are used. I think apport will ask about sending it but not > sure whether is tells you that "by the way this is 20MB of data and > may contain sensitive information". I doubt the average user really > wants this, let alone business users. > > My rough idea of how this could look in the end would be: - we > remove the dump functionality from kexec-tools - we replace the > kexec-tools dependency in linux-crashdump with kdump-tools - > kdump-tools would by default produce dumps but no reports (this > probably needs some thoughts about where to place those and how to > make sure they don't overflow the fs). - we can figure out a way to > extract information we need for reports locally and then only > report things with as little data as possible (maybe require a > setting to enable this). > One option to extract some reporting information could be to extract the content of the dmesg in a separate file and include only this in the apport report. makedumpfile has a --dump-dmesg option that can do that in a separate pass. While this works well on Debian, it fails on Quantal so maybe some more information might be needed in our kernel to achieve this. Only a few more lines are required in /usr/sbin/kdump-config which is part of the kdump-tools package. If this sounds reasonable, I will investigate our kernel requirement so this can work on Ubuntu as well. Any comment ? Kind Regards, ...Louis - -- Louis Bouchard Backline Support Analyst Canonical Ltd Ubuntu support: http://landscape.canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD9VA4ACgkQDvqokHrhnCzn3gCg9R5UrxNnI93wjaKvOvMzFKs8 /qEAoLOkO17o7QX1DvA+wG3U6w3z2W/k =7xoP -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
gpg key error when trying to add a PPA
I keep getting this error when trying to add the ppa. I realized that my key used to sign the CoC was the older one, with which LP created the PPA. I have deactivated the old key and signed the CoC with my new key. But how do I update the new key to the PPA? rrs@zan:~/devel/Laptop-Mode-Tools/laptop-mode-tools (ubuntu)$ sudo add-apt-repository ppa:rrs/laptop-mode-tools You are about to add the following PPA to your system: PPA for Laptop Mode Tools This PPA is created for the latest and greatest version of Laptop Mode Tools. Please note that this PPA also ships a modified version of pm-utils, where all overlapping features have been removed from the pm-utils package. So if you run into power related problems, do not just file a bug report on Launchpad. Investigate first. Use at your own risk. More info: https://launchpad.net/~rrs/+archive/laptop-mode-tools Press [ENTER] to continue or ctrl-c to cancel adding it Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python3.2/threading.py", line 740, in _bootstrap_inner self.run() File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 141, in run self.add_ppa_signing_key(self.ppa_path) File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 223, in add_ppa_signing_key tmp_keyring, tmp_secret_keyring, signing_key_fingerprint, tmp_keyring_dir): File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 145, in _recv_key if not verify_keyid_is_v4(signing_key_fingerprint): File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 126, in verify_keyid_is_v4 return len(signing_key_fingerprint) >= 160/8 TypeError: object of type 'NoneType' has no len() -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
